Serwer Blade vs Serwer Normalny: Które Ustawienie dla CCcam/OScam?

\n\n

Jeśli planujesz infrastrukturę CCcam lub OScam, prawdopodobnie natknąłeś się na pytanie o serwer blade w porównaniu do serwera normalnego. Wybór ma większe znaczenie, niż byś myślał, zwłaszcza gdy zaczynasz uruchamiać obciążenia związane z udostępnianiem kart, które nie zachowują się jak typowe aplikacje w centrum danych.

\n\n

Większość przewodników porównawczych serwerów całkowicie ignoruje specyfikę udostępniania kart. Porównują architekturę serwera blade i normalnego w kontekście baz danych w chmurze i usług internetowych, gdzie wzorce obciążenia są całkowicie różne. Żądania deszyfrowania ECM działają inaczej. Wymagania dotyczące wiązania portów są surowsze. Problemy z izolacją nie są takie same. Ten przewodnik omawia to, co naprawdę ma znaczenie, gdy budujesz środowisko serwera CCcam lub OScam.

\n\n

Różnice w architekturze: Serwer Blade vs Tradycyjny Projekt Serwera

\n\n

Fizyczny format i projekt obudowy

\n\n

Serwer blade to cienki, samodzielny moduł komputerowy, który wsuwany jest do wspólnej obudowy. Pomyśl o tym jak o karcie w slocie. Wiele blade'ów mieści się pionowo w jednej obudowie—zazwyczaj 10 do 16 jednostek w standardowej szafie. Każdy blade ma własny procesor, pamięć RAM i pamięć (zwykle dyski SAS lub SSD), ale dzieli ramę obudowy, zasilacze, wentylatory chłodzące i infrastrukturę przełączania sieciowego.

\n\n

Normalny serwer—czy to wieżowy, czy montowany w szafie—jest samodzielną jednostką z własną płytą główną, zasilaczem, systemem chłodzenia i połączeniami sieciowymi. Siedzi niezależnie w szafie lub na półce. Możesz go usunąć, zaktualizować lub wymienić bez wpływu na inne serwery.

\n\n

Dla obciążeń związanych z udostępnianiem kart, ta różnica ma natychmiastowe znaczenie. Środowisko serwera blade łączy twoje instancje mechanicznie. Środowisko normalnego serwera utrzymuje je oddzielnie.

\n\n

Modele łączności sieciowej

\n\n

Obudowy blade zawierają wewnętrzny przełącznik backplane. Zamiast tego, aby każdy blade potrzebował indywidualnych kabli sieciowych prowadzących do zewnętrznego przełącznika, wszystkie blade'y łączą się z siecią zainstalowaną w obudowie. To brzmi efektywnie, dopóki nie zdasz sobie sprawy, że tworzy to pojedynczy punkt konfliktu.

\n\n

Gdy uruchamiasz instancje CCcam lub OScam, każdy port nasłuchujący potrzebuje responsywnego wejścia/wyjścia sieciowego. Jeśli wiele instancji wiąże się z portami w zakresie 12000-13999, a cały ruch przepływa przez ten sam fizyczny uplink z obudowy do twojej sieci rdzeniowej, stworzyłeś wąskie gardło. Normalny serwer z niezależnymi kartami sieciowymi gigabitowymi może rozdzielać ruch inaczej—na przykład jedna instancja na kartę NIC.

\n\n

Uplinki obudowy blade są zazwyczaj podwójnymi lub poczwórnymi połączeniami gigabitowymi. Dla małych konfiguracji udostępniania kart (2-4 instancje serwera) może to wydawać się wystarczające. Ale gdy jednoczesne żądania ECM wzrastają w różnych instancjach, przełącznik backplane blade staje się ograniczeniem, a nie twoje połączenie sieciowe z ISP.

\n\n

Systemy dystrybucji energii

\n\n

Serwery blade dzielą modułowe zasilacze zainstalowane w obudowie. Typowa obudowa blade ma 2-4 redundantne zasilacze. Jeśli jeden zawiedzie, pozostałe jednostki rozdzielają obciążenie. Brzmi dobrze w teorii.

\n\n

W praktyce, jeśli twoja obudowa ma budżet energetyczny 4 kW i uruchamiasz 12 blade'ów, każdy blade otrzymuje średnio około 333 watów. Gdy intensywne obliczenia deszyfrowania ECM zachodzą jednocześnie na wielu blade'ach, pobór mocy wzrasta. Wspólna szyna zasilająca widzi łączny popyt. Jeśli całkowity popyt przekracza dostępną pojemność, obudowa automatycznie ograniczy lub wyłączy blade'y o niższym priorytecie.

\n\n

Normalne serwery mają wbudowane redundantne zasilacze. Awaria jednego zasilacza 500W w normalnym serwerze wpływa tylko na tę jednostkę. Reszta infrastruktury działa dalej. Tracisz jedną instancję CCcam, a nie wiele.

Zasoby współdzielone vs dedykowane

Każdy komponent w środowisku serwerów blade jest albo współdzielony, albo ściśle powiązany. System chłodzenia obsługuje wszystkie blade'y. Sieć zarządzająca jest zjednoczona. Oprogramowanie układowe działa na poziomie szafy i wpływa na wszystkie blade'y podczas aktualizacji. Pamięć masowa w środowiskach blade zazwyczaj łączy się z współdzielonym SAN, a nie z bezpośrednio podłączonymi dyskami.

Normalne serwery są niezależnymi maszynami. Jeśli jeden zawiedzie, inne działają dalej. Jeśli musisz zaktualizować BIOS lub oprogramowanie układowe, robisz to na jednej jednostce, nie dotykając reszty. Pamięć masowa jest lokalna—brak zależności od SAN lub opóźnień.

Dla odpornej konfiguracji udostępniania kart, separacja jest preferowana. Nie chcesz, aby współdzielona infrastruktura powodowała awarie w twoim wdrożeniu.

Rozważania dotyczące wydajności dla obciążeń związanych z udostępnianiem kart

Wzorce alokacji CPU i RAM

Udostępnianie kart nie jest wymagające obliczeniowo według standardów centrów danych. Jedna instancja CCcam lub OScam obsługująca 100-200 aktywnych użytkowników zużywa około 1-2 rdzeni CPU i 1-2 GB RAM. Ograniczeniem nie jest surowa moc obliczeniowa—jest to opóźnienie sieciowe i responsywność I/O.

W serwerach blade, wszystkie blade'y na tej samej szafie konkurują o ten sam budżet chłodzenia i szynę zasilającą. Jeśli jeden blade obciąża CPU na poziomie 90% przez dłuższy czas (dekodowanie ECM pod obciążeniem), generuje ciepło, które wspólny system chłodzenia musi rozproszyć. To wpływa na warunki termiczne dla sąsiednich blade'ów.

Normalne serwery obsługują stałe obciążenie CPU niezależnie. Możesz uruchomić jeden serwer na poziomie wykorzystania CPU 80% 24/7, nie wpływając na inny serwer obok niego.

Wąskie gardła I/O w architekturze blade

To jest kompromis między serwerem blade a normalnym serwerem, który ma największe znaczenie dla udostępniania kart. Kiedy konfiguruje się wiele instancji CCcam na jednym blade, każda instancja wiąże się z różnymi portami nasłuchującymi (12001, 12002, 12003 itd.). Na poziomie sieci wszystkie te porty kończą się na tym samym fizycznym interfejsie wewnątrz blade'a—połączeniu z przełącznikiem szyny.

Pod dużym obciążeniem, przełącznik szyny staje się punktem serializacji. Nadchodzące żądania ECM kolejkowane są w oczekiwaniu na ten pojedynczy interfejs, aby je przekazać. Normalne serwery z wieloma niezależnymi kartami sieciowymi nie mają tego problemu. Każda karta sieciowa obsługuje swój własny ruch niezależnie.

Możesz uruchomić CCcam z ścieżką konfiguracyjną/etc/CCcam.cfg nasłuchującą na porcie 12000 i inną instancję nasłuchującą na porcie 12001. Na normalnym serwerze z podwójnymi kartami sieciowymi, możesz przypisać każdą instancję do oddzielnych interfejsów. Na blade, obie używają tego samego interfejsu, co niweczy redundancję.

Różnice w subsystemach pamięci

\n\n

Serwery blade zazwyczaj przechowują system operacyjny i pliki aplikacji na wewnętrznych dyskach SAS podłączonych do własnego kontrolera blade'a. Pliki konfiguracyjne—twoje/etc/CCcam.cfg,/etc/oscam/oscam.server, baza użytkowników i logi—istnieją na tej lokalnej pamięci.

\n\n

Jednak w większych wdrożeniach blade'ów, pamięć często przechodzi przez szkielet lub łączy się z zewnętrznymi SAN-ami. To wprowadza opóźnienia sieciowe w operacjach na plikach. Kiedy OScam odczytuje listę serwerów kart z/etc/oscam/oscam.server, to jest operacja na lokalnym dysku. Wprowadzenie SAN staje się operacją sieciową, dodając milisekundy.

\n\n

Normalne serwery używają pamięci bezpośrednio podłączonej. Brak opóźnień sieciowych. Pliki są lokalne. Aplikacje do udostępniania kart odpowiadają szybciej.

\n\n

Wrażliwość na opóźnienia w żądaniach ECM

\n\n

Przetwarzanie ECM (Entitlement Control Message) jest wrażliwe na opóźnienia. Opóźnienie 100 milisekund w odpowiedzi na żądanie ECM jest zauważalne dla użytkowników końcowych. Oczekuje się, że serwery będą odpowiadać w czasie 50-100 ms lub krócej.

\n\n

Infrastruktura blade wprowadza opóźnienia na wielu warstwach: przełącznik szeregowy, zmiany stanu zasilania, ograniczenia termiczne, dostęp do SAN, jeśli dotyczy, oraz kontencja w sieci zarządzającej. Żadne z tych czynników nie są przeszkodami dla pojedynczego blade'a działającego w jednej instancji, ale kumulują się, gdy uruchamiasz wiele instancji lub zarządzasz szkieletowym systemem z 8+ blade'ami.

\n\n

Normalne serwery eliminują większość tych źródeł opóźnień. Bezpośrednie połączenia sieciowe, lokalna pamięć, niezależne zasilacze, oddzielne chłodzenie. Otrzymujesz czystsze, bardziej przewidywalne czasy odpowiedzi.

\n\n

Analiza kosztów i gęstości

\n\n

Porównanie początkowych inwestycji w sprzęt

\n\n

Serwery blade wygrywają pod względem gęstości i kosztu na jednostkę, gdy wdrażasz wiele instancji. Jeśli potrzebujesz 12 jednostek serwerowych, szkielet zawierający 12 blade'ów kosztuje mniej na blade'a niż zakup 12 samodzielnych serwerów rackowych.

\n\n

Jednak konfiguracja do udostępniania kart nie potrzebuje 12 instancji. Większość realistycznych wdrożeń uruchamia 2-4 skrzynki CCcam/OScam. W tej skali kupujesz dużą szafę blade, aby zapełnić niewielką część jej pojemności. Płacisz za niewykorzystane sloty, wspólną infrastrukturę, z której nie korzystasz, oraz system zarządzania szafą, który dodaje złożoności.

\n\n

Normalny serwer w obudowie rack 2U jest znacznie tańszy niż chassis blade, gdy wdrażasz 3 lub mniej jednostek. Płacisz tylko za to, co używasz.

\n\n

Zużycie energii i koszty chłodzenia

\n\n

Chassis blade wymaga stałego dostarczania energii. Wspólne zasilacze nie mogą być tak łatwo skalowane w dół jak niezależne zasilacze. Nawet jeśli uruchamiasz tylko 3 blade w chassis na 16 slotów, zasilacze i wentylatory chłodzące muszą utrzymywać nadmiar energii na poziomie systemu.

\n\n

Serwery blade wymagają również ścisłego chłodzenia w układzie gorący korytarz/zimny korytarz w centrum danych. Chassis jest gęste termicznie - dużo komponentów w małej przestrzeni. Potrzebuje przewidywalnych wzorców przepływu powietrza. To wymusza odpowiednie chłodzenie obiektu, co zwiększa koszty operacyjne.

\n\n

Normalne serwery są bardziej wyrozumiałe. Mogą tolerować mniej niż idealne warunki chłodzenia. Nie wymagają zamknięcia gorącego korytarza. Rozpraszają ciepło bardziej stopniowo na większej powierzchni fizycznej.

\n\n

Dla małej operacji udostępniania kart, która uruchamia 2-4 normalne serwery, chłodzenie rzadko jest wąskim gardłem lub czynnikiem kosztowym.

\n\n

Metryki przestrzeni i gęstości racków

\n\n

Serwery blade doskonale sprawdzają się, gdy przestrzeń jest ograniczona. Chassis na 10 blade'ów mieści 10 instancji serwerów w 10 U (jednostkach rackowych) przestrzeni pionowej. Normalny serwer rack 2U zajmuje 2 U na instancję - 10 instancji potrzebowałoby 20 U.

\n\n

Jeśli znajdujesz się w komercyjnym centrum danych wynajmując przestrzeń rackową za 100 USD lub więcej za U miesięcznie, gęstość staje się kluczowa. Ale w przypadku udostępniania kart zazwyczaj nie potrzebujesz gęstości. Nie uruchamiasz 50 instancji. Mały rack lub nawet serwer w rogu w domu daje Ci całą potrzebną przestrzeń.

\n\n

Zaleta przestrzeni znika w przypadku małych wdrożeń. Koszt na jednostkę serwera blade w porównaniu do normalnego serwera faworyzuje blade'y tylko wtedy, gdy wykorzystujesz większość pojemności chassis.

\n\n

Koszty utrzymania i wymiany

\n\n

Awaria komponentów serwera blade jest bardziej skomplikowana. Uszkodzony dysk twardy w blade'ie można często wymienić bez wyłączania blade'a (jeśli chassis obsługuje hot-swap). Ale modernizacja RAM-u lub wymiana NIC-a wymaga usunięcia blade'a z chassis - zorganizowany proces, który wpływa na cały system.

\n\n

Normalne serwery są modułowe z założenia. Otwórz pokrywę, dodaj RAM, wymień NIC, zamknij. Żadne procedury nie są wymagane. Brak wpływu na chassis.

\n\n

W przypadku udostępniania kart, gdzie prowadzisz operacje 24/7, nieplanowane utrzymanie powinno być szybkie i izolowane. Normalne serwery to oferują. Blade'y wymagają większej koordynacji.

\n\n

Ekonomia skalowalności

\n\n

Serwery blade są ekonomiczne przy 6+ jednostkach. Gdy przekroczysz ten próg, przewaga kosztowa na jednostkę rośnie. Chassis na 16 ostrzy obsługujące 16 instancji jest tańsze na jednostkę niż 16 samodzielnych serwerów.

\n\n

Wdrożenia udostępniania kart rzadko osiągają ten poziom. Jedna dobrze skonfigurowana instancja CCcam lub OScam może obsługiwać 200-400 aktywnych użytkowników w zależności od puli kart i sieci. Dwie instancje obsługują 400-800 użytkowników. Większość operacji osiąga maksymalnie 3-4 instancje.

\n\n

Przy 3-4 instancjach porównanie serwera blade do normalnego serwera mocno faworyzuje normalne serwery. Kup dokładnie to, czego potrzebujesz. Omiń nadmiar.

\n\n

Różnice w konfiguracji i operacjach

\n\n

Dostęp do BIOS/firmware i aktualizacje

\n\n

Normalne serwery mają bezpośredni dostęp do BIOS. Restartujesz konkretny serwer, wchodzisz do BIOS, wprowadzasz zmiany i uruchamiasz ponownie. Zajmuje to 5 minut. Inne serwery działają bez zakłóceń.

\n\n

Serwery blade mają BIOS na poziomie ostrza (lokalny BIOS) i firmware na poziomie chassis (firmware zarządzające). Aktualizacja firmware zarządzającego może wymagać, aby wszystkie ostrza były offline lub w stanie ograniczonej wydajności. To zaplanowane zdarzenie konserwacyjne wpływające na wiele instancji jednocześnie.

\n\n

Dla małej konfiguracji CCcam/OScam działającej ciągle, aktualizacje firmware blade są zakłócające. Tracisz wszystkie instancje jednocześnie. W przypadku normalnych serwerów aktualizujesz je pojedynczo, rozkładając okna konserwacyjne.

\n\n

Konfiguracja sieci: dedykowane vs współdzielone porty zarządzające

\n\n

Normalne serwery mają IPMI (Intelligent Platform Management Interface) na dedykowanym porcie zarządzającym. Możesz zdalnie zarządzać serwerem—cykl zasilania, sprawdzenie statusu sprzętu, dostęp do konsoli—bez dostępu do systemu operacyjnego lub interfejsu sieciowego.

\n\n

Chassis blade mają jeden port zarządzający na samym chassis. Wszystkie ostrza są zarządzane przez ten port za pośrednictwem sieci zarządzającej lub interfejsu webowego. Jeśli port zarządzający zawiedzie lub zostanie nasycony jednoczesnymi żądaniami, tracisz dostęp out-of-band do wszystkich ostrzy w tym chassis.

\n\n

Aby rozwiązać problem z zawieszoną instancją CCcam na ostrzu, czekasz na dostępność sieci zarządzającej. Na normalnym serwerze masz bezpośredni dostęp IPMI niezależnie od innych działań na maszynie.

\n\n

Konfiguracja przekierowania portów i reguł zapory

\n\n

Każda instancja CCcam lub OScam potrzebuje skonfigurowanych portów nasłuchujących w zaporze i przekierowanych, jeśli działa za NAT. Port 12000 dla instancji pierwszej, 12001 dla instancji drugiej, itd.

\n\n

Na normalnym serwerze z wieloma kartami sieciowymi możesz przypisać różne instancje do różnych fizycznych interfejsów i zarządzać regułami zapory dla każdego interfejsu. Czystsza separacja.

\n\n

Na serwerze blade wszystkie instancje na tym blade przechodzą przez ten sam interfejs sieciowy do tylniego panelu szafy. Twoje zasady przekierowywania portów działają (router potrafi rozróżnić porty 12000 i 12001), ale sam blade nie korzysta z oddzielnych ścieżek sieciowych.

\n\n

Monitorowanie i zarządzanie poza pasmem

\n\n

Monitorowanie instancji CCcam/OScam oznacza sprawdzanie obciążenia CPU, użycia pamięci, przepustowości sieci i metryk na poziomie aplikacji (połączeni użytkownicy, czas odpowiedzi ECM itp.). Normalne serwery raportują te dane za pomocą IPMI niezależnie. Monitorujesz jeden serwer, nie wpływając na inne.

\n\n

Monitorowanie blade odbywa się przez szafę. Masowe zapytania o wiele metryk blade mogą obciążać wspólną sieć zarządzania. Możesz zauważyć sztuczne skoki opóźnienia w swoich instancjach CCcam, po prostu dlatego, że system monitorowania pyta czujniki sprzętowe na szafie.

\n\n

Wymagania dotyczące przestojów podczas konserwacji

\n\n

Normalne serwery: aktualizuj jeden, pozostawiając inne w działaniu. Okna konserwacyjne są przypisane do serwera. Możesz zaktualizować serwer A we wtorek, serwer B w czwartek. Ciągła dostępność jest możliwa.

\n\n

Serwery blade: krytyczne aktualizacje często wymagają, aby cała szafa została wyłączona. Tracisz wszystkie instancje jednocześnie. Dla ciągłej operacji udostępniania kart jest to problem. Twoi użytkownicy widzą przerwy w usłudze.

\n\n

Jeśli uruchamiasz redundantne konfiguracje (główna i zapasowa), konserwacja blade nadal jest zakłócająca. Musisz przełączyć całą konfigurację udostępniania kart na inną szafę blade podczas aktualizacji.

\n\n

Kompromisy w zarządzaniu chłodzeniem i zasilaniem

\n\n

Wzorce przepływu powietrza w blade vs tradycyjnych szafach

\n\n

Serwery blade wymagają ścisłego zarządzania przepływem powietrza. Szafa jest gęsto upakowana — wentylatory wpompowują chłodne powietrze przez wszystkie blade jednocześnie. Gorące powietrze wydobywa się z tyłu. Jakiekolwiek przeszkody lub niewłaściwe ustawienie wpływają na wszystkie blade w równym stopniu.

\n\n

Ten projekt działa doskonale w kontrolowanych środowiskach centrów danych z precyzyjnym chłodzeniem CRAC/CRAH. W mniej kontrolowanych ustawieniach (mniejsze operacje, hybrydowe konfiguracje domowe-biuro) serwery blade są delikatne. Ograniczają wydajność termalnie, jeśli przepływ powietrza jest zagrożony.

\n\n

Normalne serwery tolerują większą zmienność. Przepływ powietrza wokół jednego samodzielnego serwera nie zależy od otaczającej infrastruktury. Możesz je uruchomić w szafie z otwartym oknem i przetrwają. Nie jest to idealne, ale możliwe.

\n\n

Wymagania dotyczące redundancji zasilania

\n\n

Szafy blade zazwyczaj mają redundancję N+1 w zasilaczach. Dwa zasilacze oznaczają, że jeden może zawieść, a system nadal działa. Cztery zasilacze dają większy zapas.

\n\n

Ale redundancja w środowisku blade jest wszystko albo nic. Jeśli masz 4 zasilacze PSUs zdolne do 5 kW łącznie, a jeden zawiedzie, tracisz 25% pojemności. Wszystkie blade teraz dzielą 3,75 kW zamiast 5 kW. Jeśli twoje całkowite obciążenie jest bliskie maksimum, osiągniesz nowy limit.

Normalne serwery mają niezależną redundancję. Serwer A ma PSU1 i PSU2. Serwer B ma PSU3 i PSU4. Awaria zasilacza w serwerze A nie wpływa na pojemność zasilania serwera B.

Ryzyko throttlingu termicznego pod obciążeniem

Podczas długotrwałego odszyfrowywania ECM na wielu instancjach blade, temperatura CPU rośnie. Jeśli obudowa nie może odprowadzić ciepła wystarczająco szybko (awaria wentylatora chłodzącego, wysoka temperatura otoczenia), CPU zaczyna throttling—zmniejsza prędkość zegara, aby obniżyć wydzielanie ciepła.

Throttling CPU oznacza wolniejsze przetwarzanie ECM, wyższe czasy reakcji, pogorszenie doświadczenia użytkownika. W obudowie blade, throttling termiczny na jednym blade może spowodować, że wentylatory zaczną pracować szybciej, wpływając na wszystkie blade. Otrzymujesz kaskadowy spadek wydajności.

Normalne serwery throttlują się niezależnie. Przegrzewanie jednego serwera nie wpływa na drugi. A przy niższej gęstości, odprowadzanie ciepła jest łatwiejsze—nie pakujesz 12 gorących CPU do obudowy 10U.

Skalowanie wentylatorów blade i kwestie hałasu

Wentylatory obudowy blade są kontrolowane na poziomie obudowy. W miarę wzrostu temperatury, wszystkie wentylatory zwiększają obroty razem. Hałas wentylatorów może stać się znaczący—obudowy blade na pełnym obciążeniu brzmią jak silniki odrzutowe. Dla serwerowni sąsiadujących z biurami, to jest irytujące.

Normalne serwery mają niezależną kontrolę wentylatorów. Możesz dostosować krzywe wentylatorów dla każdego serwera bez wpływu na inne. Możesz również łatwiej tolerować hałas, zarządzając kilkoma samodzielnymi jednostkami w porównaniu do głośnej obudowy.

Dla operacji dzielenia kart, hałas ma mniejsze znaczenie niż wydajność. Ale jeśli twoje serwery znajdują się w wspólnej przestrzeni, hałas wentylatorów blade jest wadą.

Serwer Blade vs Normalny Serwer: Scenariusze z Życia Wzięte

Przejdźmy przez kilka praktycznych sytuacji, w których wybór serwera blade w porównaniu do normalnego ma rzeczywiste znaczenie.

Scenariusz 1: Zaczynając od małych (2-4 instancje)

Wdrażasz swoje pierwsze ustawienie CCcam. Początkowo spodziewasz się 200-300 aktywnych użytkowników. Jeden normalny serwer rackowy 2U działający na dwóch instancjach radzi sobie z tym łatwo. Koszt: 400-600 USD za sprzęt serwerowy, jeden kabel zasilający, jeden kabel sieciowy. Ustawienie: podłącz go, zainstaluj system operacyjny, wyodrębnij binaria CCcam, edytuj/etc/CCcam.cfg dla swoich kart i numerów portów, systemd start cccam. Jesteś na żywo w jedno popołudnie.

Ten sam scenariusz z serwerami blade: kupiłeś szafę serwerową na 16 slotów (2000-3000 USD), aby pomieścić 2 serwery blade. Zakupiłeś 2 serwery blade (400-600 USD każdy), moduły zarządzające i licencje. Podłączyłeś to do swojej infrastruktury, z uwzględnieniem zasilania i chłodzenia. Konfiguracja zajmuje tygodnie dokumentacji i konfiguracji interfejsu zarządzania. Dla 2-4 instancji, to ogromna przesada.

\n\n

Scenariusz 2: Dziedziczona infrastruktura blade

\n\n

Otrzymałeś starą szafę serwerową z 8 pustymi slotami i polecono ci wdrożyć CCcam na niej. Szafa istnieje, koszt jest już poniesiony. Teraz wdrażasz 4 serwery blade, ale możesz później rozszerzyć do 8. Spraw, aby to działało.

\n\n

Problem: Każdy serwer blade może uruchamiać wiele instancji CCcam (powiedzmy, 3 na serwer blade = 12 łącznie), ale wszystkie dzielą szynę backplane szafy. Twój ruch sieciowy jest szeregowy przez ten sam uplink. Lepiej jest uruchamiać mniej instancji na serwer blade, używając tylko 4 serwerów blade i pozostawiając 4 puste, aby uniknąć konfliktów.

\n\n

Skonfiguruj każdy serwer blade ostrożnie: 1-2 instancje na serwer blade, nasłuchujące na portach 12000-12001 dla serwera blade 1, 12002-12003 dla serwera blade 2, itd. Monitoruj wykorzystanie sieci na szynie backplane szafy. Jeśli utrzymuje się powyżej 70%, osiągnąłeś praktyczny limit na tym sprzęcie.

\n\n

Scenariusz 3: Wysoka dostępność z przełączaniem awaryjnym

\n\n

Uruchamiasz współdzielenie kart na dużą skalę—8 instancji na wielu serwerach obsługujących 1000+ jednoczesnych użytkowników. Czas działania jest krytyczny. Chcesz redundancji.

\n\n

W przypadku normalnych serwerów kupujesz 8 serwerów, konfigurujesz je identycznie i równoważysz ruch między nimi. Jeden serwer zawodzi, ruch redystrybuuje się na 7. Użytkownicy zauważają niewielkie zmniejszenie usługi.

\n\n

W przypadku serwerów blade kupujesz dwie szafy na 16 serwerów blade. Instancja 1 działa na serwerze blade 1 w szafie A, a zapasowa instancja 1 działa na serwerze blade 1 w szafie B. Cała szafa zawodzi, przełączasz się na drugą. Ale to wymaga koordynacji—zarządzasz dwoma dużymi systemami, z których każdy ma własne zasilanie, chłodzenie i sieć zarządzania.

\n\n

Normalne serwery naturalnie lepiej skalują przełączanie awaryjne. Możesz rozłożyć redundancję na różne lokalizacje fizyczne, jeśli zajdzie taka potrzeba.

\n\n

Scenariusz 4: Okna konserwacyjne

\n\n

Uruchamiasz 3 instancje CCcam na 3 normalnych serwerach. Pojawiają się aktualizacje zabezpieczeń. Aktualizujesz serwer A we wtorek, B w środę, C w czwartek. Każda aktualizacja to 10-minutowy restart. Użytkownicy pozostają na serwerach B i C, podczas gdy A jest restartowany, a następnie na A i C, podczas gdy B jest wyłączony, itd. Ciągła operacja.

\n\n

Ta sama konfiguracja na 3 serwerach blade w jednej szafie: krytyczna aktualizacja oprogramowania wymaga, aby wszystkie serwery blade były offline. Wykonujesz stopniowy restart—serwery blade wyłączają się jeden po drugim, wszystkie instancje są niedostępne, gdy każdy serwer blade jest offline (nawet jeśli tylko na 2-3 minuty). Twoi użytkownicy widzą 3-minutowe przerwy, które występują 3 razy w jednym oknie konserwacyjnym.

\n\n

Dla 24/7 współdzielenia kart, to jest niepożądane. Normalne serwery dają lepszą kontrolę.

\n\n

Kiedy serwery blade mają sens

\n\n

To nie jest "serwery blade są złe." Serwery blade doskonale sprawdzają się w określonych kontekstach. Jeśli wdrażasz 10-12 instancji CCcam, ponieważ prowadzisz dużą operację, koszty centrum danych mają znaczenie, a masz doświadczony zespół techniczny do zarządzania infrastrukturą, serwery blade stają się rozsądne.

\n\n

Na tym poziomie wynajmujesz poważną przestrzeń rackową. Chassis blade 10U z 12 instancjami jest dramatycznie tańsze niż 12 indywidualnych serwerów 2U zajmujących 24U. Efektywność energetyczna na instancję poprawia się. Wspólne chłodzenie to zaleta, gdy zarządzasz dziesiątkami instancji.

\n\n

Ale potrzebujesz umiejętności do zarządzania złożonością blade. Musisz mieć monitoring w całym chassis. Musisz rozumieć tryby awarii wspólnej infrastruktury. Dla większości wdrożeń card sharing—które mają 2-8 instancji—ta złożoność to zmarnowany nadmiar.

\n\n

Podejmowanie decyzji

\n\n

Wybierz normalne serwery, jeśli:

\n\n

\n
• Wdrażasz mniej niż 6 instancji
\n
• Chcesz prostoty i niezależności
\n
• Potrzebujesz elastyczności i izolacji na poziomie instancji
\n
• Okna konserwacyjne nie powinny wpływać na wszystkie instancje jednocześnie
\n
• Nie masz dostępnego chłodzenia w centrum danych klasy enterprise
\n
• Twój budżet jest napięty i potrzebujesz tylko tego, co wykorzystasz
\n

\n\n

Wybierz serwery blade, jeśli:

\n\n

\n
• Wdrażasz 8+ instancji jednocześnie
\n
• Masz ograniczenia przestrzeni w centrum danych
\n
• Jesteś komfortowy z zarządzaniem wspólną infrastrukturą
\n
• Twój centrum danych ma redundantne systemy chłodzenia i zasilania
\n
• Masz doświadczonych administratorów systemów zarządzających środowiskiem
\n
• Koszty początkowe są mniej ważne niż długoterminowa ekonomika na jednostkę
\n

\n\n

Dla większości operacji udostępniania kart, normalne serwery są właściwym wyborem. Są prostsze, tańsze w małej skali, łatwiejsze do zarządzania niezależnie i unikają trybów awarii wspólnej infrastruktury.

\n\n