0
Items : 0
Subtotal : 0,00 
View CartCheck Out
0
Items : 0
Subtotal : 0,00 
View CartCheck Out

W piaskownicy z Cisco UCS – Architektura – Part 1

Platforma serwerowa Cisco UCS jest na rynku jakiś czas, jednakże transformacja jaką przeszła jest stosunkowo duża. Można by powiedzieć, że 3 lata temu wyszli z wody, a teraz już wyrósł im przeciwstawny kciuk. Freud byłby z nich dumny.

cisco-logo-300x225

Przy zetknięciu z platformą UCS każdy stary wyjadacz będzie miał dziwne poczucie że coś jest nie tak. Normalnie, podłączamy blachę, ustawiamy IP, wchodzimy na panel administracyjny i uruchamiamy serwery montując ISO w celu instalacji systemu operacyjnego. Wszystko proste i oklepane jak pośladki gejszy. Cisco UCS ma zdecydowanie inną ideologię… Po podłączeniu wszystkiego i konfiguracji Interconnectów, czyli w przypadku UCS zarządzania dalej nie możemy uruchomić żadnego serwera. Po pierwsze nie wiadomo gdzie kliknąć, gdyż UCSM jest tak rozbudowany, że ciężko to ogarnąć na pierwszy rzut oka. Po drugie, same serwery blade, według ideologii Cisco są jak ludzie w korporacji – nic nieznaczącym zasobem, do którego, aby stał się przydatny należy przypisać profil… ale o tym za chwile na początku architektura, która również jest nieco inna.

Można powiedzieć, że na Cisco UCS składają się cztery główne elementy – Interconnect, IOM (Fabric Extenders – FEX), Chassis i serwery Blade. Zacznijmy więc od przerośniętych przełączników zwanych Interconnectami.

ucs_6248_lg

InterConnect jest sercem platformy UCS. Ten przerośnięty przełącznik nie tylko potrafi obsługiwać ruch LAN i SAN (FCoE), ale również, jest wyniesionym z blade systemem zarządzania. Zawsze działa w parze, w klastrze HA. Według Cisco można podłączyć do jednej party InterConnectów 40 skrzynek pełnych blade, jednak tylko 20 jest aktualnie wspieranych. InterConnect zawiera w sobie UCS Managera. Oprogramowanie to zarządza całą infrastrukturą sprzętową podłączoną do niego. Ciekawym elementem również jest fakt, że mogą to być nie tylko blade… ale o tym kiedy indziej. Mamy dwa rodzaje IC 6248 i jego starszego brata 6296. Różnią się one ilością portów oraz modułów rozszerzeń, oraz oczywiście przepustowością, więcej w tabelce poniżej:

ic_comp_tab

Tak więc w każdej instalacji UCS’ów będziemy mieli przynajmniej dwa IC, połączone w klaster HA, serwujące zarządzanie, oraz obsługujące ruch LAN/SAN z skrzynek blade. Przykładowo konfiguracja interfejsów Interconnecta 6248 wygląda następująco:

inter_back

Możemy sobie podczas planowania naszej infrastruktury założyć, że będziemy mieli więcej portów ETH a mniej FC, lub na odwrót. Pamiętajmy jednak, że nie możemy tych portów mieszać – tzn. na przykład drugi port to ETH a czwarty to FC, należy je układać w grupy, które zaczynają się w przypadku ETH od lewej a FC od prawej strony IC. Dodatkowy moduł traktowany jest podobnie – nie łączy się z numeracją IC, jak i również grupy tworzone są z dwóch stron niezależnie od IC. Konfigurację InterConnectów należy przemyśleć bardzo skrupulatnie przed instalacją. Późniejsza ich zmiana może wymusić restart urządzenia. Taka sytuacja następuję gdy kupujemy Interconnect bez modułu, a następnie decydujemy się na jego dołożenie, wtedy właśnie restart CAŁEGO urządzenia jest wymagany.

Kolejnym elementem układanki są moduły wejścia wyjścia zwane Fabric Extenders – IOM, znajdujące się w skrzynce blade na backplane.

iom

Moduł ten zapewnia nam transparentną komunikację skrzynki blade z InterConnectami, realizujemy ją zależnie od modelu 8 lub 4 portami 10GB. Możemy łączyć się 1, 2, 4, 8 lub 16 interfejsami, generalnie kolejnymi potęgami dwójki. System jest binarny, więc nie pozwoli nam na połączenie 3 kablami czy 6. Jeżeli chcemy zagregować ruch możemy do tego użyć mechanizmu PortChannel per Flow lub Discrete Mode – ich konfiguracja odbywa się na poziomie Interconectów i UCMS. Występują trzy typy modułów IOM:

iom_comp_tab

Discrete Mode jest mechanizmem umożliwiającym zmapowanie do każdego uplinka wychodzącego z modułu IOM do serwera Blade. Istnieje do tego pewna matryca, którą przedstawia poniższa tabelka:

2uplinki_tab

4uplinki_tab

8uplinki_tab

Metoda ta ma zalety i wady. Niekwestionowaną zaleta jest przewidywalność co się stanie gdy któryś z linków się uszkodzi. Sprawa jest prosta – w scenariuszu gdy mamy dwa uplinki i pada nam pierwszy to serwery 1, 3, 5, 7 tracą połączenie. Dodatkowo mamy jasność i przejrzystą sytuację jeżeli chodzi o planowanie wydajności. Wadą są poniekąd ta same cechy… Nie jesteśmy w stanie nic zrobić, gdyż niema możliwości „przełączenia” po mid-plane wirtualnie kabelka w celu naprawy łącza, czy też dodania przepustowości. Wyobraźmy sobie taką sytuację:

cisco_iom_1V

Oczywiście przy zastosowaniu dwóch modułów IOM redundancja zapewniona jest poprzez drugą ścieżkę. Więc jesteśmy zabezpieczeni i nie uświadczymy chłosty na placu pod firmą.

Sytuacja ma się nieco inaczej gdy zastosujemy Port-Channel Mode. Rozpocznijmy może od tego, na czym to polega. Port-Channel to LAC według Cisco. Dzięki niemu jesteśmy w stanie przykładowo zagregować 8 linków fizycznych 10 GB do jednego linku, 80GB. Pamiętajmy jednak, że Cisco stosuje tutaj formułę per flow, co oznacza, że każdy balansowanie ruchem odbywa się za pomocą strumieni a nie pakietów. Tak więc dla jednego flow jesteśmy w stanie uzyskać max 10GB. Niema jednak co panikować, nasze 80GB jest bowiem osiągalne… Wyobraźmy sobie taką sytuację – posiadamy 10 maszyn wirtualnych z których 7 jest bardzo wysoko obciążone, a dwie się nudzą. Dodajmy również, że duże obciążenie to 8Gbps, a nudzenie to 2Gbps. Tak więc szybko licząc, nasz Port-Channel zapchany mamy w 75% (60Gbps). Dodatkowo ruch jest zgrabnie rozłożony pomiędzy różnymi interfejsami wewnątrz Port-Channel’a.

cisco_iom_1PC

Nasuwa się jednak pytanie co się dzieje, gdy jeden, lub więcej linków pada? Tu ujawnia się pewna wada Port-Channel’a. Otóż, jak w przypadku Discrete Mode uszkodzony link przełącza się na drugą kartę w IOM B, tak tu sprawa ma się nieco inaczej. Podczas awarii zagregowany link ulega degradacji prędkości nie przełączając się na zapasową ścieżkę. Tak więc w przypadku awarii jednej ścieżki z modułu IOM do IC efekt w naszej hipotetycznej sytuacji będzie dosyć piorunujący – pamiętajmy, że mamy w użyciu 60Gbps tracimy jeden linki wiec dalej teoretycznie wszystko działa bez zarzutu… ale pamiętajmy, że ilość połączeń pomiędzy IOM a IC musi być kolejną potęgą dwójki. Tak więc mamy teoretycznie 7 linków działających i jeden uszkodzony, praktycznie jednak mamy 4, ponieważ IC/IOM wyłącza 3 działające linki zgodnie z arkanami architektury. Tak więc nasz link degraduje się z 80GB do 40GB. Można jednak zbudować reguły, że jak link zdegraduje się do 4, lub mniej fizycznych połączeń to ma przepiąć na drugiego IOM’a. Możliwości jest kilka i warto je zgłębić gdy zdecydujemy się na zastosowanie Port-Channel’a.

Kolejnym elementem UCSowej układanki jest Chassis w którym znajdują się serwery Blade. Generalnie skrzynka jest samą blachą, bez elektroniki, która została wyniesiona do modułów IOM, oraz Interconnectów.

ucs_chassis

Z tyłu znajdują się 4 moduły zasilania oraz dwa zestaw wiatraków odpowiedzialnych za chłodzenie. Minimalna ilość zasilaczy niezbędna do działania skrzynki to dwa, przy zainstalowaniu trzech chassis działa w trybie 2+1, przy czterech przełącza się w tryb Powergrid. Zasilacze są numerowane od prawej do lewej. Skrzynka zajmuje 6U i mieści się w niej 8 serwerów połówkowych i 4 pełnowymiarowe.

Serwery UCS blade można w uproszczeniu podzielić na dwa rodzaje – połówkowe i pełnowymiarowe. Poniżej można zobaczyć różnice między konstrukcją na podstawie urządzeń UCS B22 M3 (mniejszy) i UCS B420 M3 (większy).

ucs_blade_servers

Różnią się one w zasadzie ilością slotów na pamięci, CPU, karty mezzanine i dyski twarde. Reszta pozostaje taka sama, większy wygląda jak dwa mniejsze połączone razem.

Karty mezzanine w infrastrukturze UCS występują w kilku rodzajach, ale o tym następnym razem…

Artykuły powiązane:

Żródła:

About the author

Bloger i niezależny konsultant z wieloletnim doświadczeniem w branży IT. Specjalizujący się w wirtualizacji i cloud computingu. Posiada tytuły MCP, MCTS, VCP oraz VMware vExpert.
4 Responses

Leave a Reply