ś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.

Brak komentarzy:

Prześlij komentarz