W piaskownicy z Cisco UCS – Architektura – Part 2

Zastanawialiście się w ogóle skąd się wzięła nazwa Cisco? Sprawa jest w sumie logiczna i wynika z wrodzonego dla IT podchodzenia do wszystkiego po najmniejszej linii oporu. Otóż Cisco jest skrótem jaki stosowano dla nazwy San Francisco. Trudno zawyrokować, czy wybór ten wynikał z braku kreatywności twórców firmy czy z braku czasu. Patrząc jednak na ich historię, chyba nie mieli czasu na coś tak przyziemnego jak nazwa… trzeba było tyle wymyślić, tyle namieszać i tyle wynaleźć.

cisco_nad_mostem

Po szybkiej chorobie powracam do platformy UCS. Dalej kontynuujemy naszą wyprawę do krainy architektury rozwiązań zunifikowanej platformy datacenter od Cisco. Skończyliśmy ostatnio na kartach mezzanine, które możemy podzielić generalnie na trzy, główne grupy…

Low-Cost

Jest to w zasadzie najprostsza do wyobrażenia sobie grupa kart, której nazwa nie jest metaforyczna – niski koszt, oraz mało funkcji. Generalnie dostajemy dwa porty 10GB Ethernet, nic więcej nic mniej. Żadnego wbudowanego mechanizmu niezawodności, wszystko musimy robić w na poziomie OS. Droga ta przeznaczona jest dla prawdziwych oldskulowych wojów, którzy przy pomocy magii systemu operacyjnego pragną trzymać wszystko żelazną ręką.

oplin

Przykładem w tej kategorii jest to przedstawiona powyżej karta Cisco UCS 82598KR-CI z chipem Intel Oplin która posiadają dwa interfejsy 10GE, oraz programowy stos FCoE.

Compatibility

Jest to w gruncie rzeczy rozwinięta forma kart z grupy low-cost, w której znajdujemy poza 2 x 10GB Ethernet również chip odpowiedzialny za FCoE obsługiwane poprzez Menlo ASIC. Tak więc, ta grupa, to zwykłe karty CNA, które mogą być zarówno ze stajni Emulexa jak i Qlogica. Oba mają bardzo podobną konstrukcję, różniącą się chipem, przykład na układzie Qlogic:

menlo

Dzięki zastosowaniu dwóch układów, oraz chipu Menlo ASIC uzyskujemy konfigurację ścieżek wyglądającą następująco:

manlo_paths

Tak więc w każdej ścieżce mamy zapakowany ruch z jednego interfejsu HBA jak i jednego interfejsu ETH. Jednak należy pamiętać, że są to wciąż ścieżki twardo zakodowane, wiec jak padnie nam link A to tracimy karty HBA0 i ETH0 – wciąż niema mechanizmu sprzętowego w celu zapewnienia niezawodności.

Virtualization

Taak… tu zaczyna się prawdziwa zabawa. Zacznijmy od tego, że karty VIC, czyli Virtual Interface Card, w przeciwieństwie do dwóch poprzednich grup nie posiadają żadnego fizycznego interfejsu na wyjściu z karty do serwera blade… Wiem, brzmi nieco pokracznie, jednakże popatrzmy na limity wynikające z kart CNA. Zazwyczaj w systemie operacyjnym widzimy dwa interfejsy per kontroler – jeden FC drugi ETH. Tak więc są one twardo zakodowane w karcie i nie jesteśmy w stanie nic z tym zrobić, jak również nie posiadamy żadnego wsparcia od strony sprzętu w np. niezawodności. Karty wirtualne, czyli w naszym przypadku VIC prezentują nam interfejsy wirtualne. Oznacza to, że są one oderwane od sprzętu, dzięki czemu np. karta potrafi zrealizować przełączenie na ścieżkę zapasową na warstwie sprzętowej, odciążając nasz OS. Dodatkowo karta wirtualna jest tworzona na warstwie sprzętu, co oznacza, że nie tylko hypervisory będą ją obsługiwać, możemy podawać je również dla zwykłych systemów operacyjnych. Reasumując karty wirtualne są postrzegane przez OS jako karty fizyczne, a ich wirtualna natura jest dla nich transparentna.

Sprzętowe wsparcie dla mechanizmów niezawodności w tych kartach dotyczy jedynie Ethernetu. Nie wynika to z nieudolności samego rozwiązania, dotyczy to bardziej ograniczeń protokołów SAN. Przełączenie się na drugą ścieżkę jest zupełnie bezsensowne w architekturze SAN – cały ruch bowiem zostanie potraktowany jako śmieci i odrzucony. Karty VIC z konstrukcyjnego punktu widzenia były by w stanie to robić, jednakże w realnej infrastrukturze by to nie działało. Tak więc dalej jedyną drogą zapewnienia niezawodności, są dalej mechanizmy multi-path na poziomie OS.

Dla przykładu na podstawowej karcie Palo (Cisco UCS M81KR ) możemy stworzyć do 128 kart wirtualnych (jest to limit sprzętowy). Karty mogą być zarówno definiowane jako FC lub Etherent, można miksować w dowolnych proporcjach – jak wódkę z kolą. Wracając jednak na chwilę do limitów, wspomniałem już o ograniczaniu sprzętowym, istnieje jeszcze organicznie software. Realnie bowiem można bowiem stworzyć do 56 adapterów PCIe, czyli naszych wirtualnych kart. Czujecie się oszukani? Ograbieni z pozostałych 72 interfejsów? Nie ma się jednak czym przejmować, gdyż żaden system operacyjny i tak nie obsługuje tak dużej ilości kart PCIe. Poza tym było by to trochę przelewanie z pustego w próżne, gdyż dla przykładu moduł IOM sam może osiągnąć teoretyczne, zagregowane max 80GBps, tak więc zdaje się, że 256 kart 10GBPs było by książkowym przykładem over-subskrybcji.

Grupa ta posiada, poza standardową kartą Palo dwóch bardziej interesujących reprezentantów. Pierwszym z nich jest karta VIC 1280, posiadająca następującą architekturę:

1280

Jest to karta w pełni wirtualna, posiada ona 4 interfejsy 10GB per kontroler dając wstrząsające 80GBps na wyjściu z karty na świat. Tak jak wspominałem trzeba tutaj uważać, ponieważ gdy wyposażymy osiem serwerów blade w kartę tego typu to faktycznie dotrzemy do ekstazy teoretycznej wydajnościowej 640GBps… ale będzie to tylko złuda, jakościowo podobna do chrzczonej proszkiem do prania heroiny. Będziemy mieli do czynienia z przepychaniem słonia przez dziurkę od klucza – 640GBps w żaden sposób nie przeciśnie się przez 160GBps z dwóch w pełni zagregowanych modułów FEX/IOM, a warto zauważyć, że nie wspomnieliśmy jeszcze nic o limitach samego mechanizmu Port Channel per flow…

Kolejną naszą bohaterką jest karta VIC 1240. Wydaje się ona młodszą siostrą 1280, z konstrukcją prostszą i mniej wyuzdaną. Złuda. Nie dajcie się zwieść tej dziewczynce z małego miasteczka, ślicznej blondynce o niebieskich włosach i delikatnym głosiku. Wystarczy tylko bliżej się jej przyjrzeć i od razu widać jej rogi, a pantofelki, w których zawsze chodziła co niedzielę do kościoła zmienią się w plastikowe szpile na czerwonych koturnach. VIC 1240, Viki… na początku jest mała i niepozorna ale po drobnej inwestycji może nas przyjemnie zaskoczyć. Przyjrzyjmy się jej kształtom…

1240

Widać tu, że w zasadzie jest to karta VIC 1280, tylko z nieco mniejszą ilością wyjść do modułu IOM/FEX… jednak po dołożeniu specjalnego modułu, który można dołożyć później zyskuje wszelkie cechy karty VIC 1280 – 4 x 10GBps per kontroler.
Przy kartach VIC 1280 i 1240 warto wspomnieć również o technologii VM-FEX która ma za zadanie przeniesienie od maszyny wirtualnej jej równie wirtualnej karty sieciowej aż do Interconnectów i wmówienia im, że tak naprawdę jest ona wpięta prosto w jeden z ich interfejsów. Działa to tak jak na rysunku poniżej:

vm-fex-diagram

Daje to nam bardzo wysoką kontrolę nad całym ruchem sieciowym w naszej infrastrukturze wirtualnej. Dodatkowo pozwala dla zespołu sieciowego osiągnąć to co nie było do niedawna takie proste – pełną widoczność całego przepływu danych. Teraz można swobodnie analizować ruch od meandrów sieci po samą maszynę wirtualną, bez dotykania hypervisora.

karty_mezz

Oczywiście w pełni wspierana i polecana jest technologia VMDirectPath, dzięki której jesteśmy w stanie wycisnąć z kart jeszcze więcej i odciążyć CPU.

Podsumowując naszą eskapadę poprzez karty Mezzanine dla platformy Cisco UCS poniżej przedstawiam ich parametry zebrane w tabeli:

vic-table

Na dziś to już wszytko, ale niedługo kolejna cześć, w której będzie o zarządzaniu, czyli oprogramowaniu UCS Manager.

Artykuły powiązane:

Żródła: