Windows Azure – o čem se tolik nemluví

  • Article

Když jsem před 3 týdny napsal další díl seriálu „Týden v cloudu“, několik čtenářů mne decentně upozornilo :-), že jenom chválím, ale neříkám, kde použití Windows Azure není vhodné. S tímto názorem lze souhlasit a když se virtuálně postavím na druhou stranu, tam, kde stojí zákazník, musím přiznat, že bude stejně zvídavý. Ale takový je dnes svět. Když si jde člověk koupit nové auto, tak v manuálu nenajde, že průjezd kaluží s hloubkou větší než 40 cm již není výrobcem doporučován. Pokud to není zrovna off‑road, kde je hodnota 70 cm a patří mezi propagované parametry.

Povinný disclaimer

Vše, co se níže dočtete, platí v kontextu aktuální verze služeb. Většina uvedených omezení je technickým parametrem, který se může kdykoli změnit a popsané omezení pozbyde svou platnost nebo se zmenší. Jen pro pořádek – dnes máme 17.6. 2011.

Windows Azure

První si vezměme na paškál služby Windows Azure. Virtuální stroje, na kterých jsou jednotlivé aplikace spouštěny, mohou mít různou velikost. Ta se liší hardwarovými parametry, jako jsou počet procesorových jader, operační paměť nebo velikost lokálního souborového systému. Patří tam ale také např. datová propustnost na síťové kartě. Konfigurace těchto HW variant je fixní a není možné ji nijak uživatelsky modifikovat. Pokud naše aplikace např. vyžaduje „nadstandardní velikost“ operační paměti, např. větší než je 32GB, řešení ve Windows Azure neexistuje. Obdobně můžeme pohlédnout na výkon, který lze z běžícího virtuálu získat. Jednotlivá jádra jsou taktována na frekvenci 1,6 GHz. Potřebujeme-li např. co nejrychleji provádět neparalelizovatelný výpočet (na jednom jádru), unifikovaná frekvence 1,6 GHz je stropem.

Další specifickou záležitostí virtuálních strojů, o kterých ale často mluví, je nestavovost lokálního souborového systému (FS). Pokud je VM migrován, rebootován nebo vypnut/zapnut, stav FS je vrácen do původního stavu před prvním spuštěním (s výjimkou provedených updatů OS). Pokud tedy instalovaná aplikace spoléhá na perzistenci lokálního FS, pak dříve nebo později o modifikovaná data přijde. Pro toto omezení naštěstí existuje řešení – Azure Drive, Azure Storage nebo SQL Azure. Tato řešení se však neobejdou bez zásahu do aplikace nebo minimálně její konfigurace (použití Azure Drive).

Další oblastí, která má dopad na administraci a vývoj aplikací je dynamické prostředí Windows Azure. Jeden jeho aspekt je neperzistentní FS. Dalšími pak jsou – dynamicky se měnící IP adresy a názvy VM. Ty jsou jiné po každém restartu a jako uživatelé cloudu nad nimi nemáme kontrolu.

Když se posuneme o trochu výše nad samotný HW, zjistíme, že ve Windows Azure, postaveném na Windows Server 2008 (R2), nelze spustit naprosto všechny služby, které známe z běžného WS 2008. Např. nelze použít Remote Desktop Services (dříve Terminal Services). Kromě typický potřeby velké RAM pro taková řešení, je nelze ani použít z licenčního pohledu. RDS lze použít pouze pro administrativní přístup, nikoli klientský.

Limitujícím faktorem pro nasazení a provoz některých aplikací může být síťová latence. Ta se pohybuje v jednotlivých regionech v hodnotách 100-200ms. Větší latenci v komunikace v některých případech očekávat i v komunikaci uvnitř cloudu, např. mezi web rolí a SQL Azure nebo Azure Storage. Pokud nejde o principiální problém, v každém případě je nutné v kódu mít kvalitně ošetřené time-outy.

Typickou vlastností cloudu je jeho elasticita – schopnost zvyšovat a ubírat výkon v závislosti na potřebě uživatelů. Ve Windows Azure se tak děje prostřednictvím spouštění a zastavování paralelně běžících virtuálních stojů se stejným obrazem (image). Ty jsou pak automaticky load-balancovány. Aplikace, které spoléhají na afinitu k jedné IP adrese nebo sticky sessions, budou mít v tomto prostředí problém. Případný náprava spočívá v odstranění stavovosti nebo využití distribuované cache pro ukládání stavu. V případě, že vyžadujeme, aby i přesto byly příchozí požadavky obsluhovány konkrétními instancemi aplikace, je nutné zajistit interní routování na aplikační úrovni.

Azure Storage

U samotné služby Azure storage je nutné brát v potaz několik omezení. Služba dovede provádět operace s omezeným počtem transakcí za sekundu nebo velikostí HTTP dotazu. Obdobě bude možné narazit na limity týkající se přenosu velkých objemů dat dovnitř cloudu. Zde sice většinou nejde o problém na straně Azure Storage, ale na straně klienta a jeho upload rychlosti. Nahrát několik TB najednou do cloudu může zabrat signifikantní dobu a v tuto chvíli neexistuje možnost zaslat datovému centru médium s daty pro jejich překopírování.

Download dat je povětšinou v pořádku a navíc je významně posílen službou CDN, která pro upload samozřejmě nefunguje.

U služby Azure Storage je také nutné brát v úvahu fakt, že každá transakce nad storage je zpoplatněna. Aplikace s algoritmy, které extrémně intenzivně s daty pracují, mohou tímto vygenerovat nemalé náklady. Optimalizace nebo třeba přesunutí dat do SQL Azure, kde se za transkace neplatí, mohou být v těchto případech na místě. Pro jisté scénáře může dobře posloužit i využití lokálního souborového systému virtuálního stroje jako R/O cache.

SQL Azure

Aplikací, které využívají SQL server je velice mnoho. Navíc využití SQL serveru z kódu aplikace se neliší od on-premise verze. SQL server se tak může jevit jako služba, kterou lze využít s nejmenší investicí do změny v kódu. To je pravda, ale samozřejmě i zde je několik ALE.

Prvním limitem, je maximální velikost jedné databáze. Ta má dnes hodnotu 50GB. Existuje sice možnost databázi logicky rozdělit metodou shardingu a dosáhnout tak nejen větší kapacity a většího výkonu, ale nejde o naprosto univerzální řešení řešící kapacitní limit a navíc jeho použití znamená zásadní zásah do aplikace.

Pokud se podíváme na funkční odlišnosti, ty jsou nejlépe česky popsány v kapitole „SQL Azure a SQL Server - Podobnosti a rozdíly“, knihy, kterou jsme před 3 týdny vydali. Zde se například dozvíme, že:

  • Nelze použít T-SQL příkazy pro zálohování a obnovu dat (existuje řešení přes snapshot a použití Datasync služby).
  • Nelze použít některé T-SQL příkazy pracující s fyzickými soubory, protože není přístup k FS SQL serveru.
  • SQL Azure nepodporuje v současnosti všechny funkce a datové typy serveru SQL Server.
  • Neposkytuje služby pro analýzu, replikaci, službu pro asynchronní komunikaci mezi databázemi (Service Broker) apod.
  • Protože správa fyzických zdrojů přísluší službě SQL Azure, zablokuje služba každý příkaz nebo parametr, který se pokusí o přímou manipulaci s fyzickými zdroji ( jedná se například o Resource Governor, informace o souborech a skupinách souborů nebo některé příkazy DDL fyzického serveru).
  • Rovněž není možné nastavovat konfi gurační možnosti celého serveru a trasovací příznaky SQL ani použít nástroje SQL Server Profiler a Database Tuning Advisor.

Mezi nepodporované služby také patří často vyžadovaný Full Text Search (např. u CMS aplikací). Existuje sice projekt Lucene.NET realizující Full Text Index, ale nad Azure Storage. V tuto chvíli také chybí implementace úplného SQL server BI stacku nebo běhu .NET kódu (SQL CLR). V beta verzi je zatím připravena jedna BI komponenta - Reporting Services.

Abych to shrnul

Z výše uvedených specifikací je zřejmé, že pro některé scénáře nebo aplikace není cloudové prostředí připraveno. S jistotou lze říci, že např. chybějící komponenty SQL Azure případně maximální velikost se budou s časem měnit k lepšímu. Jiné charakteristiky, např. latence síťové konektivity se bude měnit jen obtížně, nebo jako nestálost lokálního souborového systému webových/worker rolí Windows Azure jsou záměrem, nikoli dočasným nedostatkem.

A příště zase pohled z opačné strany – kde prakticky vidím Windows Azure jako platformu velice výhodnou.