Uběhlo přibližně 11 měsíců od doby, kdy jsme započali zatím náš nejkomplexnější projekt reorganizace celého IT. Věříme, že v některém z následujících blogů se dostaneme k detailům designu a samotné historii tohoto projektu. Dnes se však zaměříme na aktuální stav.
Nový hardware, o kterém jste se měli možnost dozvědět z blogpostu, k nám dorazil už začátkem června. Celá jeho kompletace trvala cca měsíc, přičemž výsledek je následující:
Nová architektura však není jen o novém hardwaru. Nový hardware je pouze částí celé mozaiky, která zahrnuje následující prvky:
– nový hardware
– virtualizace / logická infrastruktura
– konfigurační management
– admin team/change management
Už nějakou dobu, především poslední dva měsíce, pracujeme hlavně na konfiguračním managementu, automatizaci a virtualizaci. Pro tyto účely jsme byli nuceni osvojit si množství nových technologií. Za všechny vzpomenu CFEngine3 a OpenStack. Bylo jich však podstatně více.
Naším cílem je dosáhnout automatického vygenerování celého systému na nových serverech, od automatizované instalace fyzických serverů, přes instalaci OpenStack až po vytvoření logické infrastruktury z virtuálních serverů pro službu sdíleného hostingu. Všechno se to děje na základě „programu“, který píšeme v jazyce CFEengine3 a představuje tak jakési DNA nového IT.
Tyto pokusy probíhají během integračního testování, které proběhlo v srpnu už třikrát, přičemž každým dalším pokusem jsme dosáhli vyšší míru automatizace. V současnosti jsme na prahu čtvrtého integračního testu, kde už bude doplněna poslední chybějící součást – automatizovaná instalace OpenStack.
Jen pro představu: instalaci fyzického serveru s OS Ubuntu minimal jsme byli schopni pomocí automatizace zkrátit na úroveň 3 minut oproti přibližné půlhodině a více, když se vše dělalo ručně. Zde se ukazuje síla automatizace – 10-násobné zkrácení času bez lidského zásahu výrazně šetří čas a snižuje náklady.
OpenStack
OpenStack zažívá v tomto období obrovský růst a denně do jeho projektů přibývají stovky změn od jeho vývojářů. Je to komplexní balík projektů, které není vůbec jednoduché rozběhat na produkční úroveň, i když existují různé one-click instalace. Častokrát je nutné čtení zdrojových kódů jako dokumentace, fixování různých bugů vlastními nebo již existujícími patche. Na produkční nasazení je nutné překonat řadu problémů a naučit se rozumět OpenStack, což trvá obvykle několik měsíců. U nás toto seznamování probíhá již přibližně 4-5 měsíců.
V případě produkčního nasazení v rozsahu WebSupportu je nutné zvážit, co potřebujeme a co ne. Nejkomplikovanější se ukázal být networking, resp. projekt Neutron, který je určen k vytváření tzv. Software Defined Network. Ty umožňují vytvářet různé virtuální sítě, vzájemně oddělené pro různé “nájemníky”. “Nájemníkem” se zde chápe někdo, kdo má vyhrazenou pouze část zdrojů z cloudu.
Ze začátku neplánujeme poskytovat přímý přístup k API OpenStack zákazníkům, ale doufáme, že v blízké budoucnosti to dořešíme.
Networking je však jediná věc, která nás spojuje se starým IT, takže nezačínáme na zelené louce, ale musíme být zpětně kompatibilní. Neutron nám to neumožňoval. Pro přidanou komplexnost a ne úplnou připravenost jsme se rozhodli SDN aktuálně nepoužít. Myslíme však na budoucnost, takže jsme promysleli, jak by se to dalo později zapracovat.
Další věcí na zvážení byl výběr použití diskového systému pro ukládání obrazů instancí. V OpenStack jsou možnosti použít ne-perzistentní diskové obrazy přes aplikaci Nova nebo perzistentní přes aplikaci Cinder. Jelikož Cinder lze propojit přímo s diskovým polem NetApp , volba byla jasná.
Často se setkáváme s názorem, že samotný OpenStack je jakási forma virtualizace. To ale není úplná pravda, vzhledem k tomu, že o virtualizaci se stará hypervisor jako Xen, KVM apod. OpenStack je soubor programů s definovaným rozhraním (API), které zajišťují orchestraci (řízení) procesů v souvislosti s životním cyklem virtuálních serverů. Jaký hypervisor je použit je vysloveně na uživateli.
Několik let již používáme na tuto orchestraci soubor vlastních skriptů, které však nejsou tak komplexní jako OpenStack, který vyvíjejí stovky developerů.
Dlouho jsme řešili výběr mezi Xenomit a KVM. Vzhledem k dlouholeté zkušenosti se Xenomit jsme byli dlouho nakloněni této alternativě. Integrace a podpora KVM do OpenStack se však ukázala jako klíčová, a tak jsme se přiklonili ke KVM.
Vytvoření paralelní IT infrastruktury pro nás znamená i možnost zahodit některé verze programů a nahradit je novými. Ke změně dojde následovně:
– databáze MySQL 5.0 a 5.1 budou přesunuty na MariaDB 5.5
– mezi podporované PHP přibude PHP 5.5
– rušíme podporu eAccelerator a nahradíme ho xcache
– měnit verzi PHP nebude možné přes .htaccess soubor, ale jen přes webadmin rozhraní
– v případě virtuálních serverů přechází ze Xenu na KVM
Všem uživatelům zároveň doporučujeme upgradovat na verzi PHP 5.3 a vyšší. V případě MySQL databází na verzi 5.5.
Verze:
– MySQL 4.0,4.1
– PHP 4.4.9
Na hostingu budou použitelné i nadále, avšak nebudou mít k dispozici tolik zdrojů jako novější verze. O všech detailních změnách a samotné migraci budeme samozřejmě informovat.
2 reakce na „Jak pokračujeme s novou architekturou“
Spravne :) KVM je best :)
[…] procenta globálně. Vše je plně automatizované a funguje to fakt skvěle. Nedávno jsme o tom psali. Tolik k vysokému standardu, který je dnes samozřejmostí nejen u nás. Co nás odlišuje od […]