środa, 10 października 2018

Migracja data centre do VMWare vCloud Air przy uzyciu Hybrid Cloud Managera.

Jednym z celow naszego projektu byla konsolidacja data centre i migracja do rozwiazania, ktore pozwoli zaoszczedzic na utrzymaniu data centre. Robilismy rozne prezentacje w jaki sposob dokonamy migracji, jakie technologie wchodza w gre, itp. Ostatecznie ktos na gorze zdecydowal sie na zakup prywatnej chmury od VMWare - vCloud Air i Hybrid Cloud Managera.

Dosc szybko okazalo sie, ze wiele obietnic nie zostanie spelnionych, np migracja miedzy data centre przy uzyciu VMotion. Dodatkowo, tuz po podpisaniu umowy, VMWare sprzedal vCloud Air firmie OVH.

Rozwiazanie zostalo wdrozone, stworzonych zostalo kilka srodowisk vCloud Air, z roznym przeznaczniem: Core, Core-Test, SQL i SQL-Test. Srodowisko SQL zostalo stworzone dla maszyn, ktore wymagaja oddzielnej licencji MSSQL.

Glowne elementy Hybrid Cloud Managera to:
- HCX Enterprise, plugin instalowany i podlaczony do lokalnego vCenter
- HCX Cloud - zainstalowane u dostawcy vCloudAir
- Elementy sieciowe:
  • Cloud Gateway (CGW)
  • WAN Optimizer
  • Layer2 Concentrator
VMware Hybrid Cloud Extension - umozliwiajace migracje maszyn miedzy lokalnym srodowiskiem, a chmura
vCloud Director  - do zarzadzania maszynami w chmurze

To jest bardzo ogolny i uproszczony opis srodowiska. Dokladniejszy opis elementow z ilustracjami znajduje sie na tym blogu: https://www.cloudbbq.com/2018/01/19/vmware-hybrid-cloud-extension/

Praktycznie od poczatku mielismy mnostwo problemow z migracjami, rozciaganiem sieci, zwijaniem sieci, firewallami i wszystkim co sie da. Wiele patchy napisano specjalnie dla nas. Bylo wiele upgrade'ow poszczegolnych elementow, noce i dnie spedzone na conference calls.

Na poczatku robilismy migracje uzywajac opcji Disaster Recovery, ktora jest podobna do SRMa. Niestety w ktoryms momencie VMWare powiedzial, ze nie bedzie supportowal nas jesli bedziemy korzystac z tej opcji i musielismy przejsc na uzywanie Bulk Migrations. Wiele aplikacji sklada sie z 40-60 serwerow, ktore mialy byc migrowane w jedna noc, ale okazalo sie, ze maszyny nie synchronizowaly sie na czas lub nie chcialy zmigrowac sie w dostepnym oknie.

Opis dostepnych metod migracji: https://www.cloudbbq.com/2018/02/13/vmware-hcx-migration-methods/ i zrzuty ekranowe z HCX z opisem krokow przy konfiguracji migracji: http://www.cloudbbq.com/2018/03/30/vmware-hcx-migration-workflow/ 
Proces, ktory ma miejsce w tle wyglada tak:
1. Stworzenie kopi maszyny w chmurze i wstepna synchronizacja dyskow
2. Synchronizacja delty
3. Maszyna przechodzi w stan gotowosci do migracji i czeka na ustawiona date i czas.
4. W oknie migracji: maszyna wylacza sie, dokonuje ostatecznej synchronizacji online, wlacza sie w chmurze.

Jedna aplikacje probowalismy zmigrowac 3 razy i 3 razy poleglismy. Jest to najwazniejsza aplikacja w firmie.
1. Za pierwszym razem baza danych nie zsynchronizowala sie na czas.
2. Za drugim razem ustawilismy synchronizacje duzo wczesniej i na krotsze interwaly synchronizacji delty, zeby bylo mniej danych w czasie ostatecznej synchronizacji. 3 dni przed data migracji, nastapil problem z infrastruktura w chmurze, a nikt nie monitorowal jej po stronie OVH. W zwiazku z tym synchronizacja bardzo spowolnila i nie bylo szans, zeby wszystko zrobilo sie na czas.
3. Za trzecim razem glowna baza danych nie zsynchronizowala sie na czas, bo nastapilo spowolnienie z powodu alertow na storage w chmurze.
Miala byc czwarta proba, ale ostatecznie firma matka powiedziala, ze ta aplikacja pojdzie do fizycznego data centre. Nie ma sie co dziwic, ze firma matka postanowila, ze pozostale dwa data centre nie beda szly do tej chmury.

Niektore z maszyn firmy sa bardzo duze i maja ogromny przemial danych. W przypadku tej aplikacji, mielismy dwa serwery z baza danych, replikujace sie miedzy soba, kazdy po 3.5TB danych. W czasie weekendu, glowna baza danych mielila po 1TB danych w ciagu 2-3h i te dany nieustannie replikowaly sie na drugi serwer.

Najwiekszym problemem chmury jest to, ze nie mamy kontroli nad tym co dzieje sie po drugiej stronie i widzimy tylko nasze zasoby w vCloud Director, natomiast nie mamy dostepu do monitoringu, ani zarzadzania infrastruktura na ktorej stoi chmura. Oczywiscie takie jest zalozenie, ze klient nie musi martwic sie tym co jest pod spodem, kupuje tylko dostepne zasoby i zarzadza swoimi maszynami. Jakikolwiek problem z maszynami trzeba zglaszac do suportu i czekac, az ktos podejmie zgloszenie i skontaktuje sie z klientem. Wlasciciel infrastruktury powinien monitorowac srodowisko i sprawdze wszystkie alerty.

Spedzilam mnostwo czasu na conference calls z OVH. Pracownicy z biura w Irlandii byli naprawde dobrzy w te klocki, ale ich zadaniem nie byl support. Oni tylko zrobili wdrozenie. Support jest w Indiach. Czasami zdiagnozowanie prostego problemu zajmowalo godziny, bo technicy nie znali naszej infrastruktury, ani historii problemow.

Oczywiscie te wszystkie nieudane proby migracji przyniosly mi ekstra pieniadze w postaci nadgodzin, ale z technologicznego punktu widzenia, bylo to bardzo frustrujace. Nauczylam sie dosc sporo w tym czasie, ale duzo firm nie korzysta z tych produktow i nie wiem czy bede miala okazje to wykorzystac.

Nie polecilabym tego rozwizania dla duzej firmy, ktora ma obecnie wlasne data centres. Moze dla malej sprawdza sie lepiej, szczegolnie bez serwerow gigantow z duzym przemialem danych.

poniedziałek, 8 października 2018

Zmierzch kontraktu nr 10 - aktualizacja jesienna.

Czas na update, od lutego troche zmienilo sie.

Sprawa przyjezdzania do biura wymyslona w lutym, rozmyla sie po okolu 2 miesiacach. Generalnie planowalismy prace wieczorne na poniedzialki i srody, zeby uniknac obowiazkowego przyjazdu do biura we wtorki i czwartki. Ostatni raz bylam w biurze pod koniec kwietnia, a potem dopiero w lipcu, gdy przychodzil nowy kontraktor i trzeba bylo go wprowadzic w obowiazki.

W czerwcu odszedl moj kolega, ktory byl technical lead. Mieli zatrudnic kogos innego, ale ja przejelam jego obowiazki, co zaowocowalo duza iloscia nadgodzin w lipcu i sierpniu. Nowy technical lead przyszedl dopiero we wrzesniu, ale tak naprawde nigdy nie zostal liderem, bo zwyczajnie nie znal historii projektu, stal sie jednym z inzynierow.

31 sierpnia oznajmiono nam, ze nowy wlasciciel korporacji ma inna wizje na przyszlosc i nasz projekt zakonczy sie wczesniej, po tym jak zmigrujemy jedno z data centre do chmury. Pozostale dwa maja zostac na razie w fizycznym data centre i nowy wlasciciel zastanowi sie co dalej. Pare osob mialo miec przedluzone kontrakty do konca pazdziernika i listopada, czesc miala odejsc pod koniec wrzesnia. Na dzien dzisiejszy jest nas piecioro plus dwie osoby, ktore maja przejsc do naszego teamu z innej czesci projektu i support teamu. Programme manager nie przedluzyl umowy w ostatniej chwili, wiec mamy teraz "nadzorce" z firmy matki, ktory jest w biurze w Wiedniu.

Ja mialam obiecane przedluzenie do konca pazdziernika, co odpowiadalo mi, bo w polowie miesiaca jade na dlugi wyjazd, wiec w sam raz ukladalo sie wszystko. Po powrocie w polowie listopada mialam zamiar zaplanowac kolejny wyjazd, ktory pierwotnie planowalam w przerwie swiatecznej w grudniu. Skoro mialam miec wolne, to po co wpychac wyjazd w swieta, jak mozna pojechac przed szczytem sezonu.

Moj agent zaskoczyl mnie, mowiac ze ma dla mnie przedluzenie do konca lutego, ale po zakonczeniu projektu bede musiala przejsc do support teamu i przyjezdzac do biura. Zgodzilam sie na przedluzenie na tych warunkach, wychodzac z zalozenia, ze po prostu odejde jak skonczy sie projekt. Na pewno nie mam zamiaru dojezdzac 3-4 razy w tygodniu po 3-4h dziennie. Pociagi z mojego miejsca zamieszkania sa troche szybsze, ale trzeba przesiasc sie do Jubilee Line w Londynie, co nie jest zabawne w godzinach szczytu. Dojazd samochodem powinien zajac tyle samo czasu lub troche mniej, bez cial obcych w najblizszym otoczeniu, nie mniej, nie planuje tego robic.

Na razie caly czas siedze w domu i ostatnio nie mam zbyt duzo pracy, bo firma matka zarzadzila kompletny change freeze w produkcji i skrocila okno, kiedy mozemy robic zmiany w srodowisku. Wczesniej moglismy robic zmiany od niedzieli wieczorem do czwartku wieczorem, teraz okno jest od poniedzialku do srody. Weekend jest kluczowy dla dzialalnosci firmy, stad to ograniczenie. O technicznej stronie projektu napisze w osobnym poscie.

Maz mial przerwe od konca kwietnia do lipca i wrocil w to samo miejsce na kolejny kontrakt. Ma miec prace do konca roku, a co potem, to zobaczymy.

Podsumowujac, postepujemy zgodnie z powiedzeniem: "invoice and smile".