30 July 2022
Jak zmigrowaliśmy platformę wirtualizacji bez zakłócania procesu produkcji w Grupie Kęty
Klient:
Grupa Kapitałowa Kęty
sektor:
Produkcja
Grupa Kapitałowa Kęty
Grupa Kapitałowa składa się z 24 spółek i prowadzi działalność w ramach trzech segmentów biznesowych. Każdy z segmentów posiada spółkę wiodącą, której nazwa jest jednocześnie główną marką stanowiącą o rozpoznawalności produktów danego segmentu na rynku. Są nimi: Grupa KĘTY S.A., Aluprof S.A. oraz Alupol Packaging S.A. Spółka specjalizuje się w produkcji profili, komponentów i zewnętrznych rolet okiennych wykonanych z aluminium. Jej działalność obejmuje też montaż fasad aluminiowych oraz wytwarzanie opakowań giętkich.
Projekt pozwolił zwiększyć moc obliczeniową oraz niezawodność platformy wirtualizacyjnej Hyper-V bez konieczności zwiększenia ilości licencji
Tomasz Michałek – Kierownik ds. infrastruktury IT w Grupie Kęty S.A.
cel projektu:
Migracja platformy wirtualizacji
Migracja platformy wirtualizacji ze środowiska Cisco UCS B200M4 na platformę Lenovo ThinkSystem SR650 V2. Wirtualizacja środowiska serwerowego u Klienta działa w oparciu o technologię Hyper-V firmy Microsoft w wersji 2016. Na potrzeby ww. środowiska wykorzystywano 6 fizycznych serwerów Cisco UCS B200M4 pracujących w trybie failover rozciągniętych pomiędzy 2 lokalizacjami oddalonymi od siebie o 40 km. Na ww. platformie zainstalowano łącznie 240 serwerów wirtualnych świadczących zróżnicowane role takie jak:
- serwery baz danych
- serwery pocztowe
- serwery aplikacyjne
- serwery plikowe
- serwery typu: MES, CRM
- systemy operacyjne różnych typów: Windows, Linux.
Wymienione wyżej usługi są krytyczne z punktu widzenia Klienta, w związku z tym nie jest dopuszczalna przerwa w ich pracy podczas migracji.
Wyznaczone podstawowe cele:
- migracja do wersji Microsoft HyperV 2019
- przeprowadzenie migracji w taki sposób by zapewniona była ciągłość pracy wszystkich usług pracujących na migrowanej platformie.
- uzyskanie większej mocy obliczeniowej oraz dostępnej pamięci RAM.
- zwiększenie wydajności kart HBA do 16Gb/s
- optymalizacja wydajności dzięki zastosowaniu technologii RDMA
Przebieg wdrożenia
- Klient zdecydował się na wybór platformy sprzętowej firmy Lenovo składającej się z 6 serwerów serii ThinkSystem SR650 V2 każdy w konfiguracji z 2 procesorami 16 rdzeniowymi, 1,5TB pamięci RAM, 2 dyskami SSD 480GB, 4 interfejsami Ethernet 10/25Gb, 2 interfejsami FC 16/32Gb. Dostarczony sprzęt został objęty 5 letnią gwarancją producenta z 24 godzinnym czasem usunięcia awarii. Platforma sprzętowa jest zarządzana za pomocą oprogramowania Lenovo XClarity Pro
- W obrębie istniejącego klastra nastąpi wymiana serwerów metodą usuwania starych węzłów klastra i zastępowaniem ich nowymi. Wybrana metoda jest przeznaczona dla wykonania update’u środowiska na tym samym sprzęcie, jednak ze względu na konieczność zachowania ciągłości pracy jest to jedyna dostępna metoda, która nie wymaga przerwy serwisowej.
- Nowe serwery zostały podłączone do sieci SAN linkami 16 Gb z zachowaniem redundancji. Każdy serwer jest wyposażony w 2 karty HBA, każda z nich została podłączona do osobnego fabrica sieci SAN.
- Połączenia do sieci LAN realizowane są pomocą 2 kart 10 Gb zagregowanych z wykorzystaniem technologii Switch Embedded Teaming (SET) i podłączonych do dwóch różnych przełączników Cisco Nexus9000. Na ww. teamie zostały wykreowane wirtualne interfejsy przeznaczone do wewnętrznej i zewnętrznej komunikacji zgodnie z zaleceniami Microsoft.
- W celu odseparowania obciążenia hosta do obsługi ruchu sieciowego obecnie wykorzystywane technologie Virtual Machine Queue (VMQ), Virtual Receive Side Scaling (vRSS) zostały zastąpione przez Dynamic Virtual Machine Multi-Queue (VMMQ) oraz Remote Direct Memory Access (RDMA)
- Na głównych przełącznikach w Data Center zostały uruchomiono polityki QoS
- Zmieniono tryb agregowania połączeń LAN z LBFO na SET tak aby korzystać z technologii: Datacentre bridging (DCB), Receive-side Checksum offloads, Remote Direct Memory Access (RDMA), Single root I/O virtualization (SR-IOV), Transmit-side Checksum offloads, Virtual Machine Queues (vVMQ), Virtual Receive Side Scaling (vRSS)
- Dodano nowe węzły do obecnego klastra i wykonano w kolejnych krokach następujące czynności: udostępniono zasoby dyskowe dla nowych hostów, zmodyfikowano pule MAC adresów na nowych hostach, włączono obsługę protokołu SMB dla LiveMigration, Ustawiono 15 równoległych kolejek dla LiveMigration, Ustawiono 4 równoległe kolejki dla StorageMigration
- Przeniesiono maszyny wirtualne w trybie LiveMigration na nowe hosty
- Usunięto stare hosty z klastra.
Wyzwanie
Głównym ryzykiem podczas migracji był tryb mieszany klastra w trakcie pracy serwerów różnych producentów. Tryb ten został wcześniej przetestowany w warunkach laboratoryjnych. Okres pracy w tym trybie został maksymalnie skrócony i ograniczył się tylko do czasu migracji maszyn wirtualnych.
Efekty prac
Bardzo istotne znaczenie w projekcie miało zastosowanie odpowiedniego planu i harmonogram migracji poszczególnych maszyn, które musiały odbywać się w dokładnie określonym czasie ze względu na konieczność zachowania ciągłości działania w trybie 24/7 systemów produkcyjnych .
- Dostarczenie platformy sprzętowej zapewniającej odpowiednią moc obliczeniową, pamięć oraz możliwość wykorzystania nowych funkcjonalności.
- Brak wpływu obsługiwanego przez serwery ruchu sieciowego na obciążenie CPU hostów dzięki zastosowaniu technologii RDMA.
