V poslední době se objevilo mnoho článků o platformě Azure. Volně by se daly rozdělit do dvou kategorií – buď jsou to rozvláčné marketingové materiály anebo odvážné technologické vize. Bohužel ani jedna z těchto dvou skupin nedává běžnému IT člověku příliš přesnou představu, jak vlastně celá Azure platforma funguje. V tomto miniseriálu se proto pokusím přiblížit její technickou podstatu srozumitelnou řečí, zejména porovnáním s dosud používanými postupy při vývoji aplikací. Začnu službou Windows Azure Compute, tedy možností pronájmu výpočetní kapacity formou virtuálních počítačů.
Základní dohoda
Princip rozdělení kompetencí je poměrně jednoduchý a bez nároku na právní či technickou přesnost by se dal popsat takto:
Microsoft vlastní obrovské množství serverů umístěných v datových centrech na 3 kontinentech (Evropa, Severní Amerika, Asie).
Zákazník (tedy případně vy) nám dodá zabalenou aplikaci v jedné ze 3 dohodnutých forem.
Podle instrukcí zákazníka vytvoříme virtuální počítače s OS Windows Server 2008 (nebo 2008 R2) v dohodnutém počtu a dohodnuté HW velikosti a aplikaci na ně nainstalujeme. Za tuto službu si účtujeme jednak hodinovým časem existujících virtuálů (0.12 USD/hodina pro nejběžnější velikost virtuálu), jednak podle GB přenesených dovnitř a ven (0.10 USD/GB směrem do cloudu, 0.15 USD/GB opačným směrem). Neplatí se žádné další poplatky za licenci, za hardware ani za cokoliv jiného.
Zákazník může na vlastní riziko měnit nastavení operačního systému a instalovat do něj další software.
Nicméně za správu a aktualizaci operačního systému je plně zodpovědný Microsoft, který může v případě HW závady, instalace aktualizací nebo jakéhokoliv jiného důvodu kdykoliv znovu provést krok 3 (tzv. re-image)
Pokud chcete nasadit novou verzi vaší aplikace, dodáte nám nový balíček. Krok 3 se opakuje s novou verzí balíčku, staré virtuály se zruší, to vše bez jakéhokoliv výpadku. Pokud chcete, můžete starou a novou verzi aplikace provozovat po nějaký čas paralelně.
Je nutno dodat, že veškeré operace v datovém centru řídí plně automatizovaný proces zvaný Fabric Controller, lidé pouze monitorují jeho funkci. Do vašich aplikací nemá žádný „živý“ administrátor přístup.
Jaké aplikace lze provozovat?
Výše jsem zmínil 3 možné formy zabalení aplikace, nyní je správný čas si je projít:
Zabalená webová aplikace (tzv. web role) – v podstatě zabalená složka souborů, která se rozbalí do adresáře a namíří se na něj web server IIS. Vhodné pro aplikace, které zpřístupňují svoje funkce přes HTTP protokol, tedy webové servery anebo webové služby
Zabalená jiná aplikace (tzv. worker role) – zabalená složka souborů, která se rozbalí do adresáře a spustí se libovolný kód. Vhodné pro aplikace, které provádějí zpracování na pozadí, mají různé výpočetní funkce anebo třeba pro provoz webových aplikací na jiném webovém serveru než IIS. Jsou podobné službám operačního systému.
Zabalený disk virtuálního počítač (tzv. VM role) – zabalený VHD soubor pro technologii Hyper-V, ze kterého se vytvoří virtuální počítač. Vhodné pouze ve výjimečných situacích, např. pokud potřebujete mít nainstalovanou aplikaci, jejíž instalaci nejde automatizovat. Používání této role je pracné, musíte se starat sami o aktualizace OS, a nemůžete si uvnitř virtuálu ukládat žádná data trvalé povahy – kdykoliv může být proveden re-image, čímž o tato data přijdete. Pokud můžete, této roli se vyhněte – je určena pouze pro specifické situace.
Protože existuje celá řada předsudků o tom, co lze ve Windows Azure provozovat, rád bych výslovně uvedl že:
Lze provozovat jakýkoliv kód, nikoliv pouze .NET framework. Namátkou lze provozovat nativní kód v C++, PHP, Javu, Ruby, ...
Při startu role můžete spustit libovolný skript, a to dokonce s právy administrátora. Můžete tak nainstalovat libovolný software, zaregistrovat COM/COM+ komponenty, měnit nastavení operačního systému, nainstalovat moduly web serveru, spustit původně nenainstalované služby operačního systému a mnohé další
Váš kód může běžet s právy administrátora (přestože to z bezpečnostního hlediska není vhodné)
K počítači se lze připojit přes Remote Desktop, provádět pak diagnostiku nebo jakékoliv úpravy. Pozor, kdykoliv může dojít k operaci re-image, proto raději veškeré úpravy dělejte ve skriptech při startu role.
Omezení při vývoji aplikací
Omezení ve skutečnosti není mnoho, je ale dobré o nich vědět. Většina aplikací lze převést pro běh na Windows Azure s minimálními úpravami.
Aplikace neběží jako administrátor operačního systému (pokud to sami nechcete). To by mělo být normou při provozu aplikace kdekoliv, nejenom v cloudu.
Aplikace nemůže zapisovat kamkoliv v souborovém systému, pouze do předem deklarovaných oblastí. Aplikace si tudíž nemůže ukládat data do „natvrdo“ zakódovaných cest – je třeba vždy pomocí cca 2 řádků kódu zjistit, jaká je správná, systémem přidělená cesta a používat tuto cestu.
Není možné ukládat data trvalé povahy do souborového systému, protože zde o ně můžete kdykoliv přijít. Do souborového systému si můžete ukládat různé mezivýsledky apod. Trvalá data patří do trvalých úložišť, tedy SQL Azure nebo Azure Storage.
Vzhledem k tomu, že operační systém může být kdykoliv znovuvytvořen, je třeba veškerá logovací a diagnostická data přenášet do trvalého úložiště mimo operační systém. Tato funkce je k dispozici, stačí ji pouze nakonfigurovat při startu aplikace.
Větší obrázek
Skončíme něčím, čím většina technických textů začíná – servisním modelem. Je to vlastně popis aplikace, která definuje jednotlivé role v aplikaci, počet a velikost instancí (virtuálních počítačů), povolené komunikace mezi rolemi i zvenčí (tzv. endpointy), používané certifikáty, lokální úložiště a řadu dalších věcí. V nejjednodušším případě má aplikace jeden server webové role nebo např. farmu 2 serverů ve web roli, mezi kterými funguje rozkládání zátěže. Ve složitějších případech to mohou být třeba 2 instance webové role pro zpracování požadavků a řádově stovky worker rolí zpracovávajících tyto požadavky, jako v případě renderování filmu Avatar. Pokud chcete v cloudu provozovat „velké“ aplikace s mnoha servery, je nezbytné se servisním modelem velmi podrobně seznámit.
Podrobnější technické informace naleznete v technických článcích (v angličtině), nejdůležitější z nich jsme přeložili do češtiny. Pokud si chcete vše prakticky vyzkoušet, je možné si stáhnout nástroje a zřídit bezplatný účet Introductory Special (vyžaduje zadání platební karty jako záruky, ale je zdarma – podrobné instrukce zde) a vyzkoušet praktická cvičení z Windows Azure Platform Training Kitu, případně tutoriály Quick Start.
Ve druhém díle se budu zabývat databází SQL Azure.
(článek převzat z MSDN blogu, autor Michael Juřek)
Po veskrze kladných ohlasech na první díl tohoto mini-seriálu, který se snaží vysvětlit podstatu Azure platformy bez marketingového nánosu a nadměrného vizionářství, přichází díl druhý. Podíváme se v něm na datovou vrstvu. Pro většinu aplikací si pod pojmem data představíme strukturovaná data, a zde už desítky let kralují relační databáze. Přestože se časem vynořují různé nerelační alternativy vhodné pro některé speciální scénáře, relační databáze jsou díky své vyspělosti, univerzálnosti a schopnostem zcela nenahraditelné – a nezdá se, že by se tento stav měl v dohledné době změnit. Platforma Azure proto logicky nabízí ekvivalent relační databáze SQL server v cloudu. Jedná se z 99% o stejný produkt, takže proti SQL Azure běží prakticky stejný kód a používají se stejné nástroje, nejčastěji SQL Server Management Studio ve verzi 2008 R2. Dále se tedy budeme soustředit spíše na věci, kterým se klasický SQL server a SQL Azure liší.
Základní dohoda
Microsoft provozuje velké Microsoft vlastní obrovské množství serverů umístěných v datových centrech na 3 kontinentech (Evropa, Severní Amerika, Asie), na řadě z nich běží SQL Azure
Zákazník (tedy případně vy) si na nich může zřídit virtuální databázový server, což je sada databází a uživatelských účtů, které k nim přistupují. Zřízení serveru je zdarma.
Na zřízeném serveru je možné vytvářet databáze. Za tyto vytvořené databáze se platí na denní bázi. Existují 2 edice – Web (velikosti 1 a 5 GB) a Business (velikosti 10, 20, 30, 40 a 50 GB). Pokud potřebujete větší velikost a škálovatelnost napříč servery, je možné použít tzv. sharding. Při vytváření databáze si zvolíte edici Web nebo Business a též maximální velikost databáze, která není nikdy překročena. Měsíčně pak platíte podle spotřebovaného místa v databázi, zaokrouhleno na nejbližší vyšší velikost v dané edici, a to přibližně 10 USD měsíčně za velikost 1 GB. Např. pokud si zřídíte Web edici velikosti 1 GB a spotřebujete 0.1 GB, platíte jako za 1 GB cenu 9.99 USD. Pokud si zřídíte Business edici o velikosti 40 GB a uložíte do ní 16 GB dat, platíte jako za 20 GB databázi, tedy 199.99 USD měsíčně. Do velikosti databáze se započítávají tabulky, indexy a další vytvořené objekty (jedná se v podstatě o spotřebované místo v MDF souboru). Velikost transakčního logu se nebere v úvahu.
Výše uvedený poplatek je jediný, který platíte. Neplatíte za hardware, za licence ani za uživatele. Jediným možným dalším poplatkem mohou být GB přenesené dovnitř a ven (0.10 USD/GB směrem do cloudu, 0.15 USD/GB opačným směrem). Tento poplatek ale platíte pouze tehdy, pokud data z databáze přechází přes hranice serverovny/datového centra. Pokud je aplikační vrstva rovněž v cloudu, nepřechází data z databáze hranici serverovny, tudíž se za ně neplatí.
Výše uvedená cena zahrnuje vysokou dostupnost se 3 replikami dat, automatickým přepnutím (fail-over) v případě výpadku a zálohování/obnovu proti veškerým hardwarovým a softwarovým selháním (nikoliv proti chybám uživatelů!!!)
Microsoft se stará o aktualizaci operačního systému i databázového softwaru, a to bez jakýchkoliv přerušení provozu (díky 3 replikám databází).
Z hlediska zákazníka je k dispozici “připojovací řetězec”, se kterým si s mírnými omezeními můžete dělat, co chcete – stejně jako když máte k dispozici připojovací řetězec ke klasické SQL databázi.
Pokud vás zajímá, jak je celá infrastruktura navržena a chcete nahlédnout pod pokličku, doporučuji článek Inside SQL Azure.
Co můžete a nemůžete v oblasti správy
Správcem databáze je Microsoft, nikoliv vy. Tudíž se o celou řadu věcí staráme za vás – vysoká dostupnost, správa hardware a software, obnova v případě selhání HW/SW apod. K těmto činnostem tudíž nemáte vůbec přístup a nemůžete ovlivnit další věci, které vám nepřísluší, jako je například umístění souborů na disku. Váš SQL server je pouze virtuální. Obsahuje uživatelské účty a sadu databází, z nichž každá se může být na úplně jiném hardware. Nemáte k dispozici plnohodnotnou databázi master (pouze její simulovanou podmnožinu s databázemi a uživatelskými účty), msdb ani tempdb. Nelze tudíž pracovat s objekty, které se vytvářejí na úrovni celého serveru, jako jsou např. SQL joby, certifikáty, linkované servery a další funkčnosti závislé na databázích master, msdb a tempdb. Přesnější popis najdete v Guidelines and Limitations.
Naopak vám přibývá jedna povinnost – nastavení firewallu. SQL Azure má vestavěný firewall na úrovni databáze, který lze nastavovat buď prostřednictvím portálu pro správu anebo voláním systémových uložených procedur přes T-SQL jazyk. Pravidla firewallu určují, z jakých adres je možné se k příslušnému databázovému serveru připojit.
Další povinností je správa uživatelských účtů – SQL Azure používá SQL autentizaci, Windows autentizace není možná. Veškerá komunikace s SQL Azure je vždy šifrována, nemusíte nic nastavovat.
Nezapomeňte též na zálohování dat z důvodu obnovy při lidské chybě (např. neúmyslné smazání důležitých dat). SQL Azure je v tuto chvíli zálohován a chráněn proti systémovým selháním, nicméně neumožňuje vyžádat si obnovu dat do konkrétního časového okamžiku, což je podmínka jakékoliv nápravy uživatelských chyb. Doporučuje se proto použít nástroje pro import a export dat – např. DAC v2.0 CTP anebo SQL Azure Migration Wizard. Pokud chcete, aby byla vyexportovaná data transakčně konzistentní, musíte před exportem zastavit uživatelskou aktivitu anebo si udělat konzistentní kopii databáze (za takto vytvořenou kopii platíte standardní částku dle ceníku po celou dobu její existence).
Rozdíly z pohledu vývojáře
Prvním místem, na které se podíváme, je připojovací řetězec. V tuto chvíli je podporováno připojení přes ODBC a ADO.NET, nikoliv OLEDB. Připojovací řetězec je třeba upravit následovně:
Jako jméno serveru použijte jeho DNS jméno, tedy místo Data Source=SERVER; napíšete Data Source=a1b2c3d4.database.windows.net;
Protože nelze použít integrovanou autentizaci, je třeba v připojovacím řetězci uvést jméno a heslo pro SQL autentizaci
Vždy je nutno uvést jméno databáze v připojovacím řetězci, tedy Initial Catalog=JmenoDatabaze;
Důležitým omezením je též izolace každého databázového připojení na jednu jedinou databázi, což má dva důvody. První je technický, neboť ostatní databáze serveru vůbec nemusí být umístěny na stejném počítači. Druhý je bezpečnostní – vzhledem k tomu, že na stejném počítači mohou být umístěny i databáze jiných uživatelů, nešlo by vyloučit pokusy o proniknutí do cizích, špatně zabezpečených databází. To má různé důsledky, jako například:
Databázi je nutno zadat již v připojovacím řetězci
Nelze použít příkaz USE pro přepnutí databáze
Nelze používat tříčlenné a čtyřčlenné názvy objektů (database.owner.object nebo server.database.owner.object), tudíž nelze vytvářet distribuované dotazy do dat.
Nelze používat vzdálené servery (remote servers, linked servers)
Jednotlivá databázová spojení nemohou sdílet data v tempdb
Transakce mohou být pouze nad jedním databázovým připojením a tedy jednou databází. Distribuované transakce nelze použít.
Další sada omezení spočívá v nedostupnosti některých funkcí databázového enginu, konkrétně takových funkcí, které by mohly ohrozit výkonnost serveru pro databáze ostatních uživatelů nebo při kterých není možná dokonalá izolace databází od sebe. Sem patří například full-textové indexy, možnost běhu .NET kódu v databázovém jádře (SQLCLR) a některé další – přesný seznam všech omezení je zde, případně v tomto whitepaperu. Dá se předpokládat, že omezení tohoto typu budou časem ubývat.
Poslední skupinu omezení tvoří „pravidla dobrého chování“ vzhledem k ostatním uživatelům. Do této skupiny patří například výkonnostní omezování anebo dokonce ukončení transakce, která spotřebovává nadměrné množství zdrojů – více informací najdete zde.
V příštím díle si povíme o alternativním způsobu uložení dat, kterým je tzv. Azure Storage. Pokud si chcete vše prakticky vyzkoušet, je možné si stáhnout nástroje a zřídit bezplatný účet Introductory Special (vyžaduje zadání platební karty jako záruky, ale je zdarma – podrobné instrukce zde) a vyzkoušet praktická cvičení z Windows Azure Platform Training Kitu, případně tutoriály Quick Start.
(článek převzat z MSDN blogu, autor Michael Juřek)
Po předchozích dvou dílech, které se věnovaly pronájmu operačního systému, tedy službě Compute a databázi SQL Azure přichází na řadu třetí díl, ve kterém se budu věnovat službě Azure Storage. Jedná se o poslední komponentu, která je využita – jak ostatně sám název napovídá – k ukládání dat. Tuto službu pravděpodobně využijete prakticky v každém řešení, i když třeba jenom v okrajové úloze – např. na trvalé uložení logů a diagnostických informací anebo pro dočasné uložení nasazovaného řešení. Existují tři základní typy dat, která lze v Azure Storage uložit – tabulky, BLOBy a fronty zpráv. Jednotlivé rozdílné typy se postupně probereme i s vhodným způsobem použití. Mají ovšem i některé...
...společné rysy
Jedná se o úložiště velmi levné, pouze 0,15 USD / 1 GB místa / za měsíc. Ve srovnání s databází SQL Azure je to 67x nižší cena za jednotkovou velikost.
Ale pozor, platí se za transakce proti úložišti, a to 0.01 USD za každých 10.000 transakcí, čili dolar za milion transakcí. Pro srovnání – u SQL Azure se za transakce neplatí nic. Přesnou definici toho, co je a co není transakce najdete zde.
Dalším možným poplatkem mohou být GB přenesené dovnitř a ven (0.10 USD/GB směrem do cloudu, 0.15 USD/GB opačným směrem). Tento poplatek ale platíte pouze tehdy, pokud data z databáze přechází přes hranice serverovny/datového centra. Pokud je aplikační vrstva přistupující k Azure Storage rovněž v cloudu ve stejném datovém centru, nepřechází data z databáze hranici serverovny, tudíž se za ně neplatí.
Jedná se o úložiště s prakticky neomezenou škálovatelností, neboť je rozprostřeno mezi mnoho serverů. Naproti tomu SQL Azure je vždy obsluhován jediným serverem.
Data jsou uložena ve třech replikách, tudíž jsou velmi dobře chráněna proti jakýmkoliv možným selháním.
Pro přístup k datům potřebujete tzv. účet úložiště (tzv. storage account). Ten založíte z Azure portálu. Zde získáte jméno účtu (DNS jméno vašeho úložiště) a klíč, který aplikace opravňuje k manipulaci s daty. Pomocí tohoto klíče můžete vygenerovat též dočasný klíč, který se hodí například na bezpečné povolení přístupu z klientských aplikací (více zde).
Veškeré operace nad úložištěm se provádí pomocí REST konvence a protokolu HTTP/HTTPS. Vývojáři však mají v rámcí Azure SDK k dispozici komfortní objektovou knihovnu, která je odstiňuje od všech úskalí protokolu, a to nejenom pro .NET framework, ale i pro platformy Java, PHP, operační systémy mobilních telefonů apod.
BLOBy
Nejčastěji používaným typem úložiště jsou tzv. BLOBy (binary large object). V cloud aplikacích plní stejnou roli jako sdílené složky souborového systému v klasickém světě. Je vhodné je použít na větší nestrukturované informace jako jsou například dokumenty aplikací, scanované papírové dokumenty, zálohovací soubory, videa, obrázky apod. Tyto soubory jsou uloženy ve složkách (tzv. kontejnery), analogicky jako v souborovém systému. Můžete je velmi dobře využívat i v kombinaci s SQL Azure. Například scanované dokumenty je možné ukládat v Azure Storage (je to levnější) a veškerá metadata potřebná pro vyhledání konkrétního dokumentu uložíte v SQL Azure, neboť ten nabízí vysokou rychlost a pestrou paletu možností pro rychlé dotazování do dat. Pokud chcete, můžete část BLOBů zpřístupnit i anonymním uživatelům – pak jsou přístupné pomocí jednoduchého HTTP GET příkazu a lze je tudíž využít přímo v internetových prohlížečích, např. pro zobrazení videa na webové stránce.
Zajímavým doplňkem k BLOBům je možnost využití CDN (Content Delivery Network). Tato služba je vhodná, pokud máte relativně velká a statická data, která jsou konzumována větším množstvím uživatelů ve více geografických lokalitách. Služba CDN funguje jako obrovská distribuovaná cache rozprostřená do minimálně 24 lokalit po celém světě (nejbližší k nám je v tuto chvíli Vídeň). Princip je jednoduchý. DNS jméno cache je převedeno na IP adresu v závislosti na IP adrese přistupujícího uživatele tak, aby ho obsluhovalo síťově nejbližší místo. Pokud je příslušný BLOB již v cache paměti, je vrácen okamžitě, pokud není, získá ho cache z úložiště Windows Azure a poté si jej uloží pro obsluhu dalších klientů po dobu TTL (time to live), kterou určuje vlastník BLOBu. Tím můžete výrazně urychlit dobu odezvy uživatele, aniž byste podstatně zvýšili cenu služby – jediné náklady navíc jsou transakce a objem přenesených dat potřebné pro naplnění cache z úložiště. Detailnější popis najdete na Daliborově blogu.
Tabulky
Tabulky v Azure Storage jsou příkladem třídy „no SQL“ databází. Podobají se běžným relačním tabulkám v tom, že jsou vhodné pro uložení strukturovaných dat ve formě řádků a sloupců. Na rozdíl od relačních tabulek může každý řádek obsahovat jiné sloupečky. Povinné jsou pouze 3 sloupečky – identifikátor oddílu dat (určuje distribuci na jednotlivé servery úložiště), identifikátor řádku a automaticky udržovanou časovou známku. Jinak se jedná o úložiště velmi hloupé – nezná žádnou kontrolu integrity, relace, triggery ani uložené procedury. Transakce podporuje pouze v omezené míře. Výběr dat je efektivní pouze pomocí identifikátoru oddílu a řádku. Proč ho tedy použít? Zejména pro relativně nízkou cenu a prakticky neomezenou škálovatelnost. Pokud máte velké množství strukturovaných dat, která jsou nezvládnutelná běžným relačním úložištěm, je to řešení pro vás. Troufnu si odhadnout, že ho bude používat pouze menšina projektů, ale zato ve velkém rozsahu.
Fronty zpráv
Fronty zpráv jsou specializovaným jednoúčelovým úložištěm pro asynchronní komunikaci mezi jednotlivými komponentami aplikací. Jedna komponenta ukládá do fronty zprávy, což jsou v podstatě „úkoly“ pro jinou komponentu. Tato může běžet i ve větším počtu instancí a z fronty je svým tempem vyzvedává a postupně zpracovává – je tak možné velmi jednoduše tlumit špičky rozkládáním do delšího časového úseku. Častým příkladem může být například e-shop postavený na Windows Azure, kde webové role přijímají objednávky od uživatelů, ukládají je do fronty a worker role je na pozadí zpracovávají. Fronty jsou typicky využívány aplikacemi běžícími na větším množství virtuálních serverů pro komunikaci mezi jednotlivými instancemi. V menších aplikacích bude jejich využití spíše ojedinělé.
V příštím díle, který bude prozatím poslední, si povíme něco o ostatních, méně často užívaných službách na platformě Azure.
(článek převzat z MSDN blogu, autor Michael Juřek)
V dnešním posledním díle se pokusíme lidskými slovy popsat všechny ostatní služby platformy Windows Azure. Přestože mají každá úplně jiné určení, mají jednu věc společnou a tato je odlišuje od služeb představených v prvních třech dílech (Azure Compute, SQL Azure, Azure Storage). Tou věcí je skutečnost, že nebudou použity zdaleka ve všech řešeních na platformě Azure. Jedná se o speciální služby pro určité konkrétní situace, využije je pouze menší část aplikací. Je tu ještě jedna odlišnost – zatímco služby představené v předchozích dílech jsou k dispozici v ostré verzi již řadu měsíců a lze u nich očekávat spíše evoluční vývoj než velké změny, služby představené v dnešním díle jsou často stále v Beta/CTP verzích, případně jsou sice v ostrých verzích, ale čeká je ještě bouřlivý rozvoj. Pojďme si teď tyto služby postupně probrat.
Azure Connect
V mnoha situacích je třeba, aby aplikace v cloudu komunikovaly s aplikacemi běžícími ve vaší serverovně anebo naopak, například potřebuje získat data z ERP systému běžícího on-premise. Služba Azure Connect umožňuje vytvoření jakési virtuální sítě na bázi IPv6. Tuto síť vytvoříte na portálu Windows Azure, kde rovněž definujete jednotlivé skupiny počítačů a povolená propojení mezi nimi. Na počítačích tvořících virtuální síť musí běžet speciální agent, který tuneluje komunikaci sítě přes odchozí HTTP spojení. Do počítačů ve vlastní síti a do Azure počítačů ve VM roli musíte tohoto agenta nainstalovat, do počítačů v rolích web a worker je agent instalován automaticky. Azure Connect je v současné době v CTP verzi a není nijak zpoplatněn. Více informací zde.
Azure Traffic Manager
Azure Traffic Manager je speciální DNS služba určena pro nejnáročnější aplikace, které běží ve více datových centrech současně. Má celkem 3 režimy:
Round robin – příchozí požadavky jsou rozdělovány mezi aktuálně dostupná datová centra střídavě
Performance – požadavky jsou rozlišovány tak, aby byl klient připojen vždy k nejbližšímu datovému centru, které je v danou chvíli funkční
Failover – požadavky jsou směrovány na datové centrum, které má ze všech aktuálně dostupných datových center nejvyšší nastavenou prioritu
Více informací zde. Azure Traffic Manager je v CTP verzi a není nijak zpoplatněn.
SQL Reporting Services
Uživatelům klasického SQL Serveru jsou Reporting Services známy již řadu let. Umožňují vytvářet tiskové sestavy s velmi bohatým obsahem ve špičkové grafické kvalitě, možností tisku a exportu do řady formátů. Nyní je podobná služba k dispozici i v cloud verzi, přestože má řadu omezení – datový zdroj může být pouze SQL Azure, funkčně je přibližně na úrovni Reporting Services v SQL Serveru Express, a navíc postrádá Report Manager či podobný nástroj. Hodí se tedy spíše na vkládání reportů do vlastních aplikací (ať už webových anebo desktopových, s daty v cloudu) než na samostatné BI řešení. Služba je v současné době v CTP verzi, způsob případného budoucího zpoplatnění dosud nebyl oznámen. Více informací zde.
SQL Data Sync
Tato služba umožňuje synchronizaci SQL Azure databází s jinými SQL Azure/SQL Server databázemi. Její použití je velmi flexibilní:
Synchronizace více SQL Azure databází, např. pokud produktového katalogu mezi eShopy umístěnými v různých datových centrech Azure.
Synchronizace on-premises databáze s SQL Azure databází, např. pokud potřebujete do cloudu publikovat část dat z on-premises aplikace.
Synchronizace více SQL databází umístěných v různých lokalitách ve vašich serverovnách s SQL Azure databází jako prostředníkem synchronizace.
Její funkce je postavena na bázi Sync Frameworku, na datové vrstvě se používají triggery a pomocné tabulky pro trackování změn. Služba je v současné době v CTP verzi, způsob případného budoucího zpoplatnění dosud nebyl oznámen. Veřejná verze bude k dispozici v létě, finální verze do konce roku. Více informací zde.
AppFabric Service Bus
Hlavní současnou funkcí technologie Service Bus je možnost zpřístupnění interních webových služeb (např. ERP systémů) běžících ve vaší serverovně do prostředí cloudu, aniž by bylo nutné otevírat porty na firewallu směrem do vašeho prostředí a ohrozit tak bezpečnost vašich dat. Vaše webová služba používající technologii Windows Communications Foundation (WCF) použije speciální komponentu (binding), která vytvoří bezpečný kanál směrem ke službě Service Bus (odchozí TCP nebo HTTPS spojení) a od této chvíle služba „poslouchá“ na veřejně dostupné adrese v cloudu. Veškerá volání na tuto adresu jsou bezpečným kanálem přeposílána dovnitř. Služba je ve finální verzi a stojí měsíčně 3.99 USD za jedno připojení, při větším množství připojení jsou množstevní slevy. Ze všech vyjmenovaných služeb lze právě u služby Service Bus očekávat nejbouřlivější vývoj směrem k plnohodnotnému Enterprise Service Bus (ESB) řešení a integrační platformě. Některé novinky již byly oznámeny, další lze očekávat v následujících měsících. Vývojářský popis technologie je zde.
AppFabric Access Control
Služba Access Control se hodí zejména v situacích, kdy vaše aplikace používá více než jednoho externího poskytovatele identity. Je postavena na bázi celé rodiny webových standardů (SAML, WS-Trust, WS-Federation apod.). Hlavní úlohou služby Access Control je, že Vaši aplikaci (ať již běží v cloudu či nikoliv) dokáže zcela odstínit od těchto autentizačních nuancí. Access Control jí předá jednotný token se všemi podstatnými informacemi. Při změně požadavků tak není třeba zasahovat do aplikace, stačí překonfigurovat službu Access Control. Služba má dva základní scénáře. Prvním je firemní aplikace s uživateli z více různých domén, zpravidla Active Directory zpřístupněné pomocí ADFS (Active Directory Federation Services). Druhou je veřejný web, který chce pracovat s autentizovanými uživateli a používat jejich existující přihlašovací údaje do LiveID, Google ID, Facebooku a Yahoo ID. Cena za použití bude 1.99 USD za 100.000 autentizací, nicméně během roku 2011 je služba zcela zdarma, a to i ve finální verzi 2.0. Kompletní popis služby je zde, praktické scénáře použití s možností vyzkoušení zde.
AppFabric Caching
Poslední službou je služba distribuované cache. Jedná se o ekvivalent služby caching, která je dostupná též jako součást Windows Server AppFabric pro klasické aplikace. Umožňuje velmi rychlé ukládání dat do paměti, která je dostupná pro všechny servery ve farmě. Typicky slouží k urychlení databázových operací a odlehčení databázovému serveru. Častým použitím je uložení tzv. session state jednotlivých uživatelů, neboť uživatel může během své interakce vystřídat různé servery ve farmě – nastavení webové farmy pro tuto službu je otázkou dvou zápisů do konfiguračního souboru. Služba je ve finální verzi, účtovat se bude podle velikosti cache paměti, ale do 1.8. je zcela zdarma. Více informací zde.