Cisco HyperFlex Hiperkonwergencja od Cisco #2

W pierwszej części artykułu dotyczącego hiperkonwergencji od CISCO skupiliśmy się na wprowadzeniu do świata serwerów, poprzedni wpis można przeczytać tutaj. Tym razem w tekście skupimy się na wizji rozwoju infrastruktury w centrach przetwarzania danych oraz platformie sprzętowej.

Wizja

Rys. 1. Wizja rozwoju infrastruktury w centrach przetwarzania danych. Od dedykowanych systemów do  konkretnych zastosowań po systemy uniwersalne pozwalające szybciej uruchamiać przeniesione oraz nowe aplikacje

Proces projektowania własnej realizacji hiperkonwergencji przez Cisco uwzględnia realizację następujących celów:

• szybkość i prostota, jednolita platforma zarządzania w ramach wszystkich centr przetwarzania danych, będących w utrzymaniu;
• ekonomia podobna do usług chmury publicznej, rozbudowa środowiska adekwatna do wymagań, czego efektem jest skalowanie kosztów proporcjonalnie do potrzeb (cloud as experience, cloud as economics).

Spełnienie tych postulatów wymaga nowego podejścia, które dostarcza kompleksowego rozwiązania, niezależnego od innych usług czy technologii. Integracja sieci jest krokiem, obejmuje ostatni obszar będący pod kontrolą innych dostawców, wymagający osobnego zarządzania, monitorowania i rozwoju. Kolejnym wyzwaniem jest stworzenie wydajnego, niezawodnego systemu plików, udostępnianego w ramach klastra, którego niezależne fragmenty znajdują się w poszczególnych węzłach. Ostatnim krokiem jest stworzenie rozwiązania będącego w stanie przejąć obciążenia obecnej infrastruktury często dedykowanej konkretnym zadaniom, a w szczególności gotowego na obsługę nowych aplikacji, które będą się pojawiać w kolejnych latach.

 Platforma sprzętowa

Przełącznik Cisco Noexus 9000 (opcjonalny):

• Fabric Interconnect Cisco UCS 6248UP
• Protokół vPC
• Łącza konwergentne
• Łącza interconnect
• Sieć 10 GbE
• Usługi współdzielone:
• vCenter
• DHCP
• NTP
• DNS
• Active Directory

Cisco UCS 6248UP:

• 2x Intel Xeon ES-2680 (v3 2,5 GHz)
• 384 GB (24 x 16 GB DDR4) RAM
• 1x Cisco 12G SAS RAID Controller
• lx 12O GB SATA SSD
• 1x 48O GB lub  600 GB SATA SSD
• 6x 1,2TB SAS 12 Gbs 10K RPM HDD
• Cisco VIC 1227 MLOM (2 porty 10G)
• 2x 64 GB SD Card

Rys. 2. Przykładowa platforma sprzętowa HyperFlex i jej podstawowe komponenty: serwery Cisco HX oraz przełączniki Fabric Interconnect. Poza klastrem pozostają elementy takie jak: inne przełączniki sieciowe czy vCenter, jednak są one wymagane dla poprawnego funkcjonowania całości rozwiązania. Warto zwrócić uwagę, że dla nadmiarowych połączeń sieciowych nie stosuje się protokołu VTP lecz vPC, który pozwala wykorzystywać wszystkie połączenia jednocześnie bez ryzyka powstania pętli. Do realizacji sieci nie są wymaganie konkretnie modele Nexus 9000, dlatego występują jako opcjonalne.

Podstawą klastra Cisco HX jest architektura UCS, bazująca na dwóch przełącznikach Fabric Interconnect (FI), do których podłączone są serwery typu rack wielkości 1 lub 2 RU. Przykładowe połączenie klastra przedstawiono na rysunku 2. Każdy serwer podłączony jest dwoma konwergentnymi łączami 10 GbE lub 40 GbE (w zależności od wybranej opcji) do obu FI, a FI połączone są ze sobą w celu uzyskania wspólnej warstwy zarządzania (dane pomiędzy serwerami nie są transmitowane). W prawidłowo skonfigurowanym środowisku cały ruch klastra zamyka się w obrębie jednego FI, jednak w sytuacji specyficznej awarii ruch może wychodzić do przełączników LAN w celu przekazania go do drugiego FI. Autorska architektura Cisco UCS pozwala definiować w serwerach karty sieciowe oraz światłowodowe, w wyniku czego w jednym fizycznym połączeniu może być realizowany ruch LAN oraz SAN. W sytuacji gdy dysponujemy odrębną siecię SAN, każdy FI należy niezależne z nią połączyć. Dzięki integracji automatycznie nakładane są odpowiednie polityki QoS oraz konfiguracja separacji ruchu za pomocą wirtualnych interfejsow oraz VLAN-ów, zapewniając odpowiedni priorytet dla danej klasy ruchu, a serwery uzyskują dodatkowe logiczne połączenie bez potrzeby fizycznego wpinania w nie dodatkowych komponentów. Warto wspomnieć, że dla zachowania takich samych parametrów wydajnościowych nie jest wspierana rozbudowa urządzeń Fabric Interconnect za pomocą Fabric Extenderów.

Fizyczne połączenie nie różnią się od tych stosowanych w ramach architektury USC. Występują natomiast różnice w obsadzeniu pojedyńczych serwerów dodatkowymi dyskami, a ponadto oprogramowanie uruchomione na serwerach ma wyłączność w zarządzaniu wspomnianymi dyskami.

Serwer w ramach klastra HyperFlex dostarczany jest wg wymagań klientów, zatem ilość pamięci RAM jak i procesory mogą się różnić. Przy projektowaniu klastra należy podjąć decyzję o konfiguracji all flash lub hybrydowej oraz wymaganej pojemności pojedynczego węzła. Wsparcie w takiej decyzji dostarczają oczywiście odpowiednie narzędzia Cisco, gdyż samodzielny wybór mógłby nie być optymalny. Biorąc pod uwagę wielkość serwerów mamy następujące możliwości:

• serwer 1 RU – model HX220c dla wersji hybrydowej, oraz HXAF220c dla all flash. W serwerach tych można zainstalować do sześciu dysków przeznaczonych na dane o wielkości 1,2 TB w konfiguracji hybrydowej oraz 960 GB lub 3,8 TB w konfiguracji all flash;
• serwer 2 RU – model HX240c dla wersji hybrydowej, oraz HXAF240c dla all flash. W serwerach tych można zainstalować do dwudziestu trzech dysków przeznaczonych na dane o wielkości 1,2 TB w konfiguracji hybrydowej oraz do dziesięciu 960 GB lub 3,8 TB w konfiguracji all flash. Instalowanie maksymalnie dziesięciu dysków w konfiguracji all flash nie wynika z ograniczeń sprzętowych lecz z potrzeby zapewnienie maksymalnej wydajności. W sytuacji potrzeby wsparcia dla obliczeń wykonywanych na GPU, w serwerach tej serii jest możliwa instalacji odpowiednich kart rozszerzeń.

Do buforowania operacji zapisów i odczytów zawsze stosuje się dyski SSD o pojemności 480 GB lub 1,6 TB dla konfiguracji hybrydowych. W konfiguracjach all flash dyski z tej warstwy buforują tylko operacje zapisów, stosuje się wówczas model o pojemności 800 GB.

Oprócz wymienionych dysków każdy serwer posiada dodatkową pamięć na system operacyjny hyperwizora oraz HX Controller VM.

W sytuacji gdy w klastrze wymagane jest szyfrowanie przechowywanych danych, należy to uwzględnić już na etapie zamówienia, gdyż taka funkcjonalność opiera się na dyskach ze sprzetowym szyfrowaniem (self-encrypting drives). Podejście takie pozwala zwiększyć bezpieczeństwo przechowywanych danych bez obniżania wydajności zapisów czy odczytów.

Platforma software’owa

Opis architektury platformy zaczniemy od systemu operacyjnego, który zainstalowany jest na fizycznym serwerze. Aktualnie Cisco HyperFlex wspiera tylko VMware, zatem wirtualizatorem jest ESXi. Na dedykowanej pamięci znajduje się system operacyjny firmy VMware oraz maszyna wirtualna Data Platform Controller. Pozostałe dyski twarde – dyski SSD warstwy buforującej, oraz dyski warstwy magazynowania danych – podłączone są bezpośrednio do maszyny wirtualnej kontrolera, co pozwala na wydajniejsze operacje na danych i eliminuje dodatkowe warstwy logiczne wirtualizacji. Wymagania kontrolera na zasoby obliczeniowe to 8 vCPU z rezerwacją 1080 MHz, 48 GB RAM dla serwerów 1 RU, albo 72 GB dla serwerów 2 RU.

Rys. 3. Schemat pojedynczego węzła w klastrze. Programowy element Data Platform Controller zawarty jest w maszynie wirtualnej, która ma bezpośredni dostęp do dysków twardych i zarządza znajdującymi się tam danymi.

Kolejnym elementem architektury są dwa moduły instalowane w systemie ESXi:

• VAAI – rozszerzenie znane z klasycznych macierzy, pozwala przesunąć na współdzieloną pamięć ciężar operacji związanych z zarządzaniem migawkami oraz operacjami klonowania maszyn wirtualnych. Kontrolery wirtualne wykonują te operacje pracując na metadanych, bez wprowadzania zmian do przechowywanych danych, dzięki czemu operacje te mogą być bardzo szybkie;
• IO Visor – moduł udostępniający klaster hiperkonwergentny jako zasób NFS, oraz dzielący dane na segmenty i przekazujący je dwóm lub trzem kontrolerom w klastrze. Warto zwrócić uwagę, że wymagana nadmiarowość dla nowych danych, dająca odporność na pojedyncze awarie koordynowana jest w omawianym module, a nie dopiero po dotarciu do kontrolera wirtualnego. Takie podejście potencjalnie przyśpiesza uzyskanie wszystkich potwierdzeń dla zapisów danych. Pomimo, że zasób klastra prezentowany jest poprzez protokół NFS, system plików jest nowym, autorskim, zaawansowanym produktem stworzonym razem z kontrolerem wirtualnym, zaprojektowanym do pracy w rozproszonym, wielowęzłowym środowisku.

Dla samego HyperFlex brak jest dodatkowych modeli licencyjnych, nie ma potrzeby wyboru z jakich funkcji chcemy korzystać – dostępne są wszystkie. Rozwiązanie działa już od VMware vSphere Essentials Plus wersja 6, w poprzednich wersjach VAAI dostępne było dla wyższych wersji licencyjnych (nie było dostępne dla najniższych wersji licencyjnych VMware). Jednocześnie warto dodać, że optymalna liczba węzłów w klastrze wynosi cztery, jednak dla mniejszych środowisk dostępna jest wersja HyperFlex Edge uruchamiana dla trzech węzłów bez Fabric Interconnect, w planach jest także uruchomienie wersji dwuwęzłowej – ROBO. Takie najmniejsze wdrożenia mogą skorzystać z najniższych wersji licencyjnych VMware.

Artykuł został opublikowany na łamach IT Professional.

Poniżej znajdą Państwo linki do wcześniejszych artykułów:

• Cisco HyperFlex Hiperkonwergencja od Cisco #1
• Cisco HyperFlex Hiperkonwergencja od Cisco #2
• Cisco HyperFlex Hiperkonwergencja od Cisco #3
• Cisco HyperFlex Hiperkonwergencja od Cisco #4
• Cisco HyperFlex Hiperkonwergencja od Cisco #5
• Cisco HyperFlex Hiperkonwergencja od Cisco #6
• Cisco HyperFlex Hiperkonwergencja od Cisco #7