čtvrtek 5. února 2015

Proč používat SD karty pro VMware ESXi?

Bob Plankers (blogger The Lone Sysadmin) po zveřejnění článku o tom, jak nahradil poškozenou SD kartu v jednom ze svých serverů, dostal ne úplně příznivé reakce.

Přiznává, že ne všechny SD karty jsou spolehlivé a jsou i jiné technologie, pomocí nichž můžete nasadit hypervisor jako je ESXi. Uvádí ovšem důvody, proč SD karty používat:
  1. Náklady – pro Dell PowerEdge R630 s tradičním osazením dvěma pevnými disky a s kvalitním řadičem RAID jsou dle dell.com náklady následující:
    300 GB 10K SAS 2,5“ disk: 5 400 Kč
    300 GB 10K SAS 2,5“ disk: 5 400 Kč
    PERC H730: 5 400 Kč
    Služba „Keep My Hard Drive“, 5 let: 5 400 Kč
    Elektrická energie pro toto nastavení (5,9 W na disk): 3 900 Kč (dle lokálních cen) za 5 let
    Výdaje na obsluhu – vyměňování disků, monitoring atd.: 5 000 Kč.
    Což vychází na 30 500,- Kč za server. Pro 32 uzlový cluster je to 976 000,- Kč což odpovídá ceně za tři servery za 5 let.

    Na druhé straně máme Dell Internal Dual SD Module, který stojí 2 700,- Kč na jeden server se dvěma 8 GB SD kartami. To dělá 86 400,- Kč pro 32 uzlový cluster.

    Ceny jsou přepočítány na CZK kurzem ČNB, průměrná cena 1 kWh=5 Kč.

    PERC H310/H330
    (zmiňované v komentářích k prvnímu článku) nejsou kvalitní řadiče RAID. Nejsou ani certifikované pro VMware vSAN. V tomto ohledu je jejich použití kvalitativně na stejné úrovni jako použití Internal Dual SD Module.
  2. Využívají mnohem produktivněji diskové šachty – například když chcete dát na svoje servery lokální disk, pro cachování to bude SSD (s využitím např. SanDisk Flashsoft, PernixData, vFRC atd.) nebo třeba vSAN, musíte použít dvě ze svých limitovaných diskových šachet pro bootování systému. To není nejproduktivnější využití drahých diskových šachet (a místa v datacentru).
  3. Vyhýbají se závislosti na páskáchAuto Deploy je zajímavá funkce od VMware, ale je závislá na fungující síti, DHCP & PXE & TFTP, DNS a infrastruktuře vCenter. Což je problém, když se potýkáte s výpadkem (plánovaným nebo neplánovaným) a jakákoliv část té infrastruktury je virtuální stroj.

    Jak vše obnovíte po výpadku, pokud je váš vCenter virtuální stroj? Spustíte řídící cluster, který nemá Auto Deploy…což je špatné, protože najednou máte vSphere cluster, který je obtížnější na správu, což znamená možné lidské chyby a další provozní náklady navíc. Zkuste si spočítat, kolik by to tak mohlo být navíc? Versus 2 615,- Kč za jeden server…

    Jak vše obnovíte po výpadku, pokud je váš DHCP/PXE/TFTP server virtuální stroj? Použijete Auto Deploy s lokálním cachováním, tzn. tradiční magnetická média – drahé a komplikované!

    U nás používáme spoustu virtuálních strojů k zajištění funkčnosti sítě jako je DHCP, některé DNS (polovina naší anycast DNS infrastruktury je na virtuálních strojích, polovina na fyzických hostech), carrier-grade NAT, shromažďování logů atd. A je to super! vSphere totiž dramaticky snižuje rizika a zlepšuje jejich provozuschopnost. Musí se ovšem sledovat závislosti, což není tak těžké, protože jich je málo.
  4. Vyhnou se nespolehlivým funkcím vSphere – když jsme u tématu Auto Deploy, chtěl bych říct, že se nejedná o dotaženou funkci určenou pro produkční prostředí. Za prvé, to není vůbec konfigurovatelné z grafického rozhraní vCenter. Vše se dělá z PowerShell, což je pro mnoho IT administrátorů komplikované. Lidé prostě nejsou tak dobří ve skriptování a CLI, jak by měli. Za druhé, závisí to na věčně mizerných Host Profiles. Nemyslím si, že jsem kdy viděl cluster, který by si nestěžoval na kompatibilitu s hostitelskými profily. A když se pak kouknete, co není kompatibilní, je to nějaký parametr, který je automaticky upraven vCenterem. Nebo třeba pathing lokálního řadiče RAID nebo CD-ROM disk nebo něco jiného, co by mělo být automaticky funkční. A pomáhej vám bůh, jestli chcete používat CHAP s hostitelskými profily.

    Funkce Auto Deploy mě také trochu děsí, když dojde na moje již existující datová úložiště. Nestavím ESXi hosty s připojeným úložištěm fibre channel, protože chci předejít neštěstí, kdy by se něco pokazilo a postihlo to několik stovek terabajtů dat na úložišti. Ale pokaždé, když se ESXi host bootuje z Auto Deploy, to vypadá, že bude dělat nějaké rozdělování lokálního úložiště. Nepředpokládá se, že to bude v interakci se „vzdáleným“ úložištěm, ale moc nevěřím VMware QA, zvláště s tak málo využívanými funkcemi. Nestojí to za to riziko.

    Auto Deploy a Host Profiles jsou zajímavé funkce, dokud se ale VMware bude věnovat oběma víc než doposud, nemohu vás podpořit v tom, abyste je dávali do podpory kritických cest ve vašem prostředí.
  5. Bootování ze SAN je také komplikované – tři hlavní alternativy k SD kartám jsou tradiční magnetická média, Auto Deploy a bootování ze SAN. Bootování ze SAN je další z těch nápadů, co se zdají být super na papíře, ale nevyjdou až tak dobře v reálném životě. Za prvé, podívejte se na poznámky k upgradu SAN od vašeho dodavatele disků. Věnujte pozornost všem upozorněním ohledně bootování ze SAN a při lokálním bootování. Řada dodavatelů ani nepodporuje aktualizace softwaru pole, když bootujete ze SAN.

    Za druhé, budete se znova potýkat s problémy v závislostech. Pokud bootujete lokálně, potřebujete napájení a chlazení a vše ostatní můžete vyřešit později. Pokud bootujete ze SAN, potřebujete, aby fungovalo napájení, chlazení, sítě/SAN atd., abyste vůbec začali. Může také dojít k více chybám způsobeným pochybením lidí. Někdo nezvládne změnu zónování SAN a vaše celá infrastruktura bude offline. Asi byste pak ani neměli na koho svalit vinu.

    Poslední, prostředí pro možnost vzdáleního bootování na serverech je složité na správu, neflexibilní a není úplně jednoduché na řešení problémů. Chcete-li provést změny, potřebujete být na konzoli, protože jen velmi málo z nich je ovladatelných přes typické nástroje pro správu systému. Konfigurování tohoto druhu bootování často používá strašné rozhraní BIOSu na vámi nainstalovaných CNAs nebo NICs, nebo archaické nástroje DOS, u kterých musíte přijít na to, jak je napěchovat na ISO nebo bootovatelný USB disk. To nestojí za čas nikoho z vás.
  6. Prostě to funguje! Když na to přijde, žádné z těchto přístupů k bootování ESXi hosta nemají žádnou návratnost investic. Žádnou. Takže každá minuta vašeho života, kterou s nimi strávíte, je promrhaná minuta.

    Řešení pomocí SD karet je levné jak z pohledu kapitálových, tak provozních nákladů. Nepotrvá vám dlouho vydělat 2 700,- Kč, zvlášť když vám Dell dopředu načte ESXi na vaše nové SD karty, což vám ušetří ještě více času.

    Když už je ESXi nabootované, zapisuje konfigurační data zpět na kartu(karty) pouze každých 10 minut, takže i přes omezené zapisovací cykly flash disků slušná SD karta vydrží po celou životnost serveru. A pokud nevydrží, zrcadlení je dostatečně spolehlivé, aby vás nechalo jít dál. Výměna a znovu zrcadlení je snadné, stačí napsat Yes na příkazovém řádku.

    Poslední výhodou je, že vás zachrání před tunou dalších složitostí, složitostí bez návratnosti investic. Nevím jak vy, ale já raději budu pracovat na reálných problémech, než se zabývat správou překomplikovaného prostředí.

SD karty – Úložiště tak akorát.


Žádné komentáře:

Okomentovat