Přesun MSTV.CZ do cloudu – praktické zkušenosti
Aniž byste si zřejmě povšimli nějaké změny, byla naše televize se screencasty www.mstv.cz přenesena do cloudu. Jak se můžete dočíst i v malém textu dole v patičce, běží nyní na Windows Azure a data jsou uložena v SQL Azure. Důvodem přesunu byly nižší náklady ve srovnání s dedikovaným hostovaným serverem a také jsme samozřejmě nechtěli být onou “kovářovou kobylou”. V tomto příspěvku bych se rád podělil o své zkušenosti s přenosem aplikace.
SQL Azure
Při migraci do cloudu určitě začněte s databází, je to celkem pohodlné a snadno můžete běžet testovací aplikaci u sebe proti SQL Azure databázi – stačí změnit connect string. Pokud máte Management Studio verze 2008 R2, můžete si naskriptovat databázi (schéma i data) s volbou cíle skriptování jako SQL Azure, vygenerovaný skript pustíte proti SQL Azure a je to hotové. Tedy alespoň teoreticky. V praxi zjistíte, že SQL Azure nepodporuje všechny rysy “normálního” SQL Serveru (seznam nepodporovaných věcí je zde). Ze seznamu vám nejpravděpodobněji budou chybět následující:
- Fulltextové hledání
- Možnost instalace vlastního .NET kódu do SQL enginu
- Omezení spojení na jednu databázi – zapomeňte na distribuované transakce mezi více databázemi, linkované servery, názvy objektů delší než dvě části (server.database.schema. object ani database.schema.object nepůjdou), použití příkazu USE DatabaseName apod.
Osobně jsem narazil na třetí záležitost – aplikace používala dvě databáze – jednu pro “živá” data, druhou pro logování provozu, přičemž mezi nimi byly vazby. Sloučit obě databáze do jedné za použití dvou různých schémat bylo sice přímočaré, ale pracné.
Windows Azure
Přesun ASP.NET aplikace na Windows Azure je v zásadě triviální, ale opět jsou tu ALE. Technicky stačí přidat do řešení ve VS nový projekt typu Azure Service, do něj přidaj jako web roli existující webovou aplikaci, spustit na lokálním Azure emulátoru, po odzkoušení nasadit do cloudu, spustit tam. A nyní ke zmíněným ALE. Přesun do Windows Azure je ekvivalentní spuštění aplikace v novém operačním systému, kde nejste administrátoři a ani vaše aplikace nemá administrativní práva. Pro “hodnou” aplikaci typu “šahám do databáze a ukazuji co je v ní” není třeba dělat žádné změny a vše funguje hlace. V jiných případech můžete narazit např. na následující problémy:
- Na OS ve Windows Azure není SMTP server. Můžete použít jiný svůj server, nebo např. Hotmail.
- Nelze přistupovat k souborovému systému s výjimkou oblastí definovaných v konfiguraci, a ani k těmto neznáte fyzickou cestu.
- Vaše aplikace není administrátor. Volání API vyžadujících administrátorská práva k lokálnímu počítači selžou.
- Musíte upravit logování a diagnostiku, které jsou ve Windows Azure jiné (třída DiagnosticMonitor)
- Nemáte plnou kontrolu nad konfigurací webového serveru.
V případě MSTV.CZ jsem narazil na chybějící SMTP server a použil jsem Hotmail. Logování a diagnostika problém nebyl, ale samozřejmě jsem je nastavil coby součást “dobrého vychování” aplikace. Co mne překvapilo je fakt, že vlastní webový server běží na portu 20000, i když je zvenčí na firewallu zpřístupněn na portu, který mu určíte, typicky 80. To může způsobovat potíže, pokud manipulujete s URL příchozího požadavku (např. přes Context.Request.Url), což je relativně vzácná záležitost, ale v případě MSTV.CZ využitá při přesměrování z https://it.mstv.cz na https://www.mstv.cz/it
Abych to shrnul, šlo to celkem hladce.
Michael
Comments
Anonymous
September 20, 2010
Nazorny priklad na realnem projektu je velice uzitecny. Jeste by me zajimalo jak vysla cena? Trba na porovnani dedikovaneho serveru a beh aplikace v cloudu?Anonymous
September 20, 2010
Soucasny hosting stoji pres 4000 mesicne (dedikovany server). Hostovane reseni je - databaze 10 USD, jeden server cca 85 USD, sitovy provoz jednotky dolaru, takze cca 100 USD. Neni to ale jenom o penezich - odpada prace s aktualizaci systemu, nemusim se bat HW selhani (3 databazove repliky, automaticka obnova sluzby), mam k dispozici testovaci prostredi pro nasazeni novych verzi prakticky zadarmo (nedocenitelne!) apod.Anonymous
September 20, 2010
Zarazil mě bod "Nelze přistupovat k souborovému systému s výjimkou oblastí definovaných v konfiguraci, a ani k těmto neznáte fyzickou cestu." V aplikacích často ukládám soubory do App_Data, cestu zjišťuji přes Path.Combine(HostingEnvironment.ApplicationPhysicalPath, "App_Data"), případně HttpContext.Current.Request.PhysicalApplicationPath. To bude fungovat, nebo se to v cloudu dělá jinak?Anonymous
September 20, 2010
Virtuál ve Windows Azure slouží primárně pro výpočetní výkon. Je téměř jisté, že kdykoliv v budoucnu bude nahrazen novým (například update OS, nová verze aplikace apod.). K ukládání na lokální disk lze použít Local Storage (viz např. nmackenzie.spaces.live.com/.../cns!B863FF075995D18A!265.entry), ale měl by se používat pouze pro pomíjivá data (cache výsledků, logy apod.) K čemukoliv trvalejšímu je třeba užít jiné prostředky určené pro trvalé uložení dat - Azure Storage (má speciální API) anebo relační databázi SQL Azure.Anonymous
September 22, 2010
A kde se ten hosting da objednat - zjisit co nabizi ?? aktuálne mám své aplikace na svém serveru 8 jader a 24 gb ram a 6 disku ale platim za pripojení 10 tis mesicne tak bych to mozna i vyuzilAnonymous
September 22, 2010
Veskere informace najdete zde www.microsoft.com/windowsazure Neocekavejte ale klasicky hosting - nejste spravce sveho serveru. Aplikaci zabalite do balicku a pres portal opublikujete, o pripravu virtualu a dalsi operace (aplikace patchu apod.) se stara automatizovana vrstva spravy (fabric).Anonymous
September 24, 2010
Pokud vase aplikace je skutecna aplikace (a ne udelatko typu MSTV), tak budete muset aplikaci notne upravit. napr. pouzivate SQL full-text search? Smula ten zatim neni na Azure dostupny...Pouzivate jiny full-text search, ktery pracuje s fyzickymi soubory? Smula neni dobra podpora file-systemu..... Pracujete se sessions? Musite si napsat vlastni, ty standardni nefunguji .... Vyvoj aplikaci pod Azure je slozity...devfabric neni 100% kopie Windows Azure, takze aby clovek skutecne vedel zda je kod ok ci ne, musi vzdy udelat balicek pro Azure.... Pokud MS chce aby se Azure uchytilo, mel by psat o tom, jak na veci, ktere nefunguji .... Na Marketing skoci snad jenom *****Anonymous
September 25, 2010
2 Petr Masin: Neskryvame, ze aplikace bezici na Azure se musi vejit do urcitych mantinelu (ktere se do budoucna budou rozsirovat). Pokud jsou pro nektere aplikace prilis uzke, je asi na miste zvolit alternativni formy hostingu (IaaS, Infastructure as a Service, namisto PaaS, tedy Platform as a Service). Chystame se o tom napsat delsi clanek.Anonymous
September 26, 2010
@Michael Jurek: Hezky receno :D. Ale co se tyka vlastniho prenosu skutecne SQL aplikace, ktera je zoptimalizovana, majici vetsi mnozstvi tabulek atd. clovek tvrde narazi a stane se z neho "manualni" otrok v prepisovani kodu, viz. napr. www.databasejournal.com/.../Migrating-Your-SQL-Server-Database-Applications-to-SQL-Azure.htm. Jo a to prepisovani pomoci Context.Request.Url vyuzivaji prakticky vsechny .NET weby umoznujici URL Aliasy pro ucely SEO..ani MOSS neni v tomto smeru vyjimkou....Anonymous
September 26, 2010
Pokud jde o prenos SQL skriptu, od vetsiny rozdilu pri vytvareni objektu vas odstini nastroje - viz napr. blog.sqlauthority.com/.../sql-server-generate-database-script-for-sql-azure nebo sqlazuremw.codeplex.com , behova syntaxe T-SQL je typicky stejna a nejsou s ni problemy. Pokud jde o prepisovani URL, mate pravdu, ze to dela rada aplikaci, ale typicky manipuluji pouze s relativni casti adresy (kde neni zadny problem), ne s hostname a portem - coz je misto, kde jsem osobne narazil.Anonymous
September 26, 2010
Dekuji tools zname. Castecne si musime psat vlastni, nekde musime v .NETu overridnout nektere metody atd. aby to vse vubec fungovalo...Jak jsem psal drive, je to porad takove nedotazene. Clovek pouziva mnoho nastroju ruzne posbiranych po netu, k tomu VS2010, caste updaty atd. Vzhledem k cene bych ale ocekaval trosku vyssi uroven ....Anonymous
December 14, 2010
Neexistence fulltextu na Azure nás nemusí moc trápit, protože SQL 2008 (R2) stejně nemá zcela nepochopitelně fulltext pro češtinu (viz SELECT * FROM sys.fulltext_languages order by name), smůlu máme my, Řekové (tam to chápu, ti už končí úplně), ale proč i Finové ?Anonymous
December 14, 2010
Absence českého fulltextu v SQL serveru je sice smutná, ale ne nepochopitelná. Vývoj komponent pro konkrétní jazyk nesouvisí tak moc s velikostí národa, ale se složitostí jeho jazyka. A zde je čeština, která skloňuje i jména osob a měst v mnoha pádech mimořádně složitý jazyk. Nicméně plně podporovaný modul pro český fulltext je již k dispozici, první produkt, který ho integruje, je SharePoint 2010, v SQL serveru se objeví v příští verzi.