Klient utrzymywał farmę swoich ESXi na usługach zewnętrznego providera. Dostawca oferował w swoim datacenter vCenter jako usługę, do którego dopięte były wszystkich hosty i datastore'y klienta. Niestety jak to czasem w biznesie bywa, drogi klienta i providera zaczęły się rozchodzić, a klient został z hostami bez vCenter i bez kopii konfiguracji czy switchy dystrybucyjnych..
Tutaj właśnie rozpoczyna się całą zabawa - ze względu na lokalizacje poza granicami Polski, klient nie miał też oczywiście szybkiego dostępu do interface'ów sieciowych swoich hostów. Wszystko musiało pozostać w niezmienionej konfiguracji.
Zaczęliśmy oczywiście od instalacji nowego vCenter. Zaraz po niej przyszła chwila refleksji i pytania:
1. Co stanie się kiedy przypniemy host mający już swojego vDSa do nowego czystego vCenter?
2. Czy da się przemigrować z jednego vDS na nowy vDS na nowym vCenter, w locie?
3. Jak zareagują na takie zmiany maszyny? Czy będzie downtime?
Wbrew pozorom nie są to pytania trywialne, a dłuższe googlowanie wcale nie przybliżało nas do odpowiedzi. Pozostało wybrać najmniej wrażliwy z hostów i wykonać małe "laboratorium".
To co oficjalnie radzi VMware, nie napawa optymizmem. Oficjalny KB: 1029498 mówi jednoznacznie. Jeśli chcesz zmigrować host z vDS do innego vcenter, po pierwsze zrób kopie obecnego vDSa, po drugie przenieść wszystko na standard switch, potem na nowym vCenter wykreuj vDSa z kopii i zmigruj do niego maszyny... Innej drogi oficjalnie nie ma. Oczywiście nie mogłem pójść tą drogą ze względu na brak kopii vDSa :-) i brak możliwości wykreowania dodatkowych interface'ow na standard switch. Wróćmy do naszego laboratorium i wniosków i odpowiedzi na trzy zadane wyżej pytania...
ad 1. Nie stanie się nic - wszystko dalej będzie działać jak działało, host podepnie się do nowego vCenter, wszystkie ustawienia sieciowe będzie miał takie jak przed podpięciem. Jedyne co się pojawi to wykrzyknik przy hoscie i fakt, że nie możemy zarządzać obecnymi ustawieniami sieci, są dla nas nie widoczne, co na szczęście nie przeszkadza aby móc wykonać kolejny ruch :)
ad 2. Życie potwierdziło że da się :) Mimo, że nie ma tego w żadnych KB'kach, następnym ruchem po wpięciu hostów do nowego vCenter może być po prostu stworzenie nowego switcha dystrybucyjnego, oraz podłączanie do niego hostów jednego po drugim przy pomocy "add and manage hosts"
Kolejnym krokiem jest oczywiście użycie tego kreatora, do zabrania vmniców staremu vDSowi i przypisaniu ich do nowego, a także konfiguracja network adapters maszyn wirtualnych by podłączone były do nowych portgroup na nowym switchu.
Oczywiście taka migracja wymaga od nas sporo wiedzy jak kiedyś było wszystko ustawione, jakimi vmnicami wychodziły maszyny i na jakich vlan id pracowały, aby móc taka konfiguracje odtworzyć - jednak gdy mamy tę wiedzę cały proces odbywa się niezwykle sprawnie.
ad3. Sam moment zastąpienia jednego switcha drugim jest niemal bezprzerwowy i wiąże się z podobną stratą jak w przypadku vMotion maszyny. Nasza migracja, została przeprowadzona tak, że klient downtime'u nie zauważył - co było również jednym z założeń.
Ostatnim etapem całego procesu jest usunięcie starych switchów dystrybucyjnych z hyperivisora. Jest to możliwe po "odczepieniu" wszystkich network adapterów od starej konfiguracji. Po tej czynności, wszelkie "wykrzykniki" znikają i nowe vCenter pracuje już z nowym vDSem tak jak powinno :)
Jaki morał? Nie zawsze wiedza zawarta w KB jest jedyną drogą do rozwiązania problemu - nam udało się to zrobić nietypowo - aczkolwiek równie skutecznie :). Najszybszą drogą do znalezienia rozwiązania było dla nas laboratorium - co zawsze polecam, przy bardziej skomplikowanych problemach, możliwość zbudowania czegoś na boku i dokładnego zbadania nim chwycimy się za produkcje bywa niejednokrotnie niezastąpiona.
Brak komentarzy:
Prześlij komentarz