Odkąd zajmuję się IT moim marzeniem było stworzenie infrastruktury, która pozwalałaby mi żyć – podróżować, doglądać dojrzewających winogron, spędzić czas z rodziną i przyjaciółmi czy dać ponieść się melanżowi. Dotychczas z różnych przyczyn było to utrudnione – wieczne awarie sprzętu, zasilania itp. sprawiały, że pod przekrwionymi oczami rosły mi coraz większe sińce, a zieleni mojej cery wtórowała coraz bardziej głuchota powodowana szumem tysięcy bezlitosnych wiatraków. Zapuchnięty, ślepy i głuchy postanowiłem znaleźć jakieś rozwiązanie tego palącego problemu, rozwiązanie, które pozwoliłoby mi wyjść z kazamatów serwerowni.

Po wielu narkotycznych transach bogowie zlitowali się w końcu nad swoim żałosnym szamanem i zesłali mi z nieba pewien pomysł… oczywiście w formie pytania. Mimo wielu objawień, jakoś jeszcze nie zdarzyło mi się aby bóstwa, w swej wszechwiedzy obdarowali mnie gotowym rozwiązaniem – konfigami i działającymi maszynami wirtualnymi. Zawsze tylko idea, ale w swojej wdzięczności nie marudziłem tylko gryzłem łaskę.

Pytanie brzmiało – Czy drogą wskazaną przez przodków podążać to mądrość czy strach? W wolnym tłumaczeniu z boskiego – Czy słusznie tak dużą wagę powinniśmy przywiązywać do sprzętu, czy jednak zbagatelizować jego rolę do odtwarzacza maszyn wirtualnych? Zaiste jest to pytanie bardzo sensowne, na które w moim przypadku odpowiedz była prosta – bagatelizować.

Wpadłem, więc na pomysł zautomatyzowania datacenter do takiego stopnia, żeby w przypadku mojej nieobecności z awarią mógł sobie poradzić nawet mój obdarzony iskierką bożą sługa Igor. Jego zadanie zamykałoby się na wymianie serwera blade na nowy, a cały proces instalacji, konfiguracji a na końcu migracji maszyn wirtualnych wykonywałby się samoczynnie. Postanowiłem do tego celu użyć mechanizmów zintegrowanych z vSphere – AutoDeploy, HostProfiles, PowerCLI i bóg wie czego jeszcze…

Powyżej zdjęcie Igora, żeby przedstawić wam dramatyzm mojej sytuacji i rozjaśnić dlaczego w przypadku awarii chciałbym osiągnąć następującą sytuację:

  1. Awaria ESX.
  2. HA/FT odpala maszyny wirtualne na innych hostach.
  3. Uruchomienie nowego, niedziałającego serwera blade, lub wymiana przez Igora.
  4. Botowanie po PXE jest domyślnie wiec system rozpoczyna automatycznie proces Auto-Deploy.
  5. Po pomyślnej instalacji dodawany jest automatycznie do vCenter, oraz aplikowany mu jest Host-Profile.
  6. Następnie nowy ESX automatycznie zostanie dodany do klastra.
  7. Na końcu maszyny wirtualne są migrowane przez DRS na nowe zasoby i praca jest skończona, a Igor oddala się do swojego legowiska.

Dodatkowo pomyślałem, że dobrze by było gdyby w przypadku awarii jakiegoś podzespołu system automatycznie przestawiał serwer w Maintenance Mode i wysyłał maila do Igora i do mnie, że trzeba go wymienić i zadzwonić do dostawcy w ramach gwarancji.

Tak, więc praca koncepcyjna jest za mną… czas wziąć się za robotę. Mam nadzieje, że pozytywne rezultaty przedstawię w następnych artykułach.

ps. Na razie skupiam się na stronie serwerów/VMware, kwestia sieciowa czy macierzowa itd. jest poza zakresem… przynajmniej na razie.

About the author

Bloger i niezależny konsultant z wieloletnim doświadczeniem w branży IT. Specjalizujący się w wirtualizacji i cloud computingu. Posiada tytuły MCP, MCTS, VCP oraz VMware vExpert.

Leave a Reply