Wymagania systemowe
Przed instalacją Bob on-premises upewnij się, że twoje środowisko spełnia wymagania dotyczące obsługiwanej platformy, architektury, zasobów obliczeniowych, pamięci masowej i sieci.
Wymagania zawarte w tej sekcji pomagają odpowiednio zaplanować i określić rozmiar środowiska OpenShift.
Obsługiwane wersje
Poniższa tabela zawiera zweryfikowane wersje komponentów obsługiwane w tej wersji Bob self-hosted. Upewnij się, że twoje wdrożenie używa obsługiwanych wersji Bob IDE, Bob Shell, Premium Package i OpenShift Container Platform (OCP), aby zachować zgodność i otrzymywać pełną pomoc techniczną dla produktu.
| Wersja Bob on-premises | Wersja Bob IDE | Wersja Bob Shell | Wersja Premium Package |
|---|---|---|---|
| 2.0.0 | 2.2.0 | 2.0.5 | IBM Bob Premium Package for Z 3.1.0 |
Architektura klastra
Backend Bob on-premises wymaga klastra OCP amd64 (x86_64). Wszystkie węzły robocze planujące obciążenia Bob muszą działać na sprzęcie amd64.
| Architektura | Obsługa klastra backendowego |
|---|---|
amd64 (x86_64) | Obsługiwane |
Klastry o mieszanej architekturze są obsługiwane, gdy obciążenia Bob są ograniczone do węzłów amd64 za pomocą selektorów węzłów lub taintów. Bob nie stosuje automatycznie tych ograniczeń planowania.
Obsługiwane wersje OCP
Poniższa tabela zawiera listę obsługiwanych wersji OCP.
| Wersja OCP | Status |
|---|---|
| 4.20 | Obsługiwane |
| 4.21 | Obsługiwane |
| 4.22 | Obsługiwane |
Ślad wdrożenia i rozmiarowanie
Bob self-hosted jest wdrażany jako obciążenie tenanta na zarządzanym przez klienta klastrze OpenShift Container Platform (OCP). Wymagania dotyczące zasobów różnią się w zależności od wdrożonych komponentów Bob i nie są stałe dla wszystkich instalacji.
Każde wdrożenie obejmuje Bob Core, który zapewnia podstawowe usługi platformy. Opcjonalne komponenty, takie jak Z Context tool, Z Proxy i Z Understand, wymagają dodatkowych zasobów obliczeniowych, pamięci i pamięci masowej i muszą być uwzględnione przy rozmiarowaniu klastra.
Dodatki są włączane podczas instalacji przez administratora klastra. Włączenie dodatku nie tylko zwiększa wymagania dotyczące zasobów klastra, ale także określa, czy odpowiednie uprawnienie do pakietu premium może być przypisane użytkownikom. Więcej informacji można znaleźć w Zarządzaniu uprawnieniami.
Wartości rozmiarowania w tej sekcji reprezentują łączne zasoby wymagane przez obciążenia Bob. Są one udostępniane w celu oszacowania śladu tenanta i nie mają na celu definiowania ogólnej architektury klastra. Należy określić rozmiar bazowego klastra na podstawie wymagań operacyjnych, w tym wysokiej dostępności, innych obciążeń tenantów, oczekiwanego wzrostu i narzutu usług platformy.
Poniższe wartości reprezentują sumę skonfigurowanych żądań zasobów podów dla wszystkich komponentów Bob przy określonych liczbach replik. Jest to ilość CPU i pamięci, którą harmonogram Kubernetes rezerwuje na węzłach klastra.
Wartości te są przeznaczone wyłącznie do celów planowania pojemności i rozmiarowania. Nie reprezentują obserwowanego zużycia zasobów w czasie wykonywania i nie należy ich interpretować jako gwarantowanego zużycia zasobów pod obciążeniem.
Decyzje dotyczące rozmiarowania klastra, takie jak liczba węzłów płaszczyzny kontrolnej, węzłów infrastruktury, węzłów roboczych, wymagania dotyczące wysokiej dostępności i planowanie wzrostu, pozostają twoją odpowiedzialnością.
Serwowanie modeli (wnioskowanie) nie jest uwzględnione. Szacunki zasobów w tej sekcji nie obejmują węzłów GPU, infrastruktury do serwowania modeli ani innych zasobów wymaganych do hostowania i serwowania modeli AI. Jeśli uruchamiasz wnioskowanie modeli przy użyciu Red Hat OpenShift AI lub oddzielnej platformy do serwowania modeli, planuj i rozmiaruj te środowiska niezależnie od wdrożenia Bob.
Obsługiwane konfiguracje stosu
Przy rozmiarowaniu klastra OpenShift zapoznaj się z konfiguracją najbardziej zbliżoną do planowanego wdrożenia.
| Konfiguracja stosu | CPU (raw) | Pamięć (raw) | Pamięć masowa (PV) |
|---|---|---|---|
| Bob Core | 10,8 vCPU | 10,8 GiB | ~24 GiB |
| Bob Core + Z Context tool | 27,8 vCPU | 45,8 GiB | ~55 GiB |
| Bob Core + Z Understand | 18,8 vCPU | 49,8 GiB | ~24 GiB |
| Bob Core + Z Context tool + Z Understand | 35,8 vCPU | 84,8 GiB | ~55 GiB |
Bob Core stanowi minimalną obsługiwaną konfigurację wdrożenia. Wartości zasobów reprezentują łączne wymagania tenanta Bob i nie uwzględniają narzutu infrastruktury platformy.
Ślad zasobów Bob
Następujący wzorcowy ślad dotyczy wdrożenia Bob Core bez włączonych opcjonalnych dodatków.
Przy rozmiarowaniu węzłów roboczych używaj wartości z wiersza +25% marginesu planowania. Wartości te zapewniają dodatkową pojemność powyżej skonfigurowanych żądań zasobów podów, aby uwzględnić wymagania harmonogramowania Kubernetes i narzut na poziomie węzła.
| Profil wdrożenia | CPU | Pamięć | Pamięć masowa (PV) |
|---|---|---|---|
| Produkcja (żądane zasoby) | 10,8 vCPU | 10,8 GiB | ~24 GiB |
| Produkcja (z 25% marginesem planowania) | ~13,5 vCPU | ~13,5 GiB | ~24 GiB |
Zużycie pamięci masowej różni się w zależności od wolumenu obciążeń, przechowywanych danych i włączonych usług. Podane wartości reprezentują podstawowy ślad dla wdrożenia Bob Core.
Topologia klastra OpenShift
Poniższa tabela przedstawia minimalną produkcyjną konfigurację wzorcową dla dziewięciowęzłowego klastra OpenShift z wdrożeniem Bob Core. Jeśli wdrażasz dodatkowe komponenty Bob, musisz zapewnić dodatkową pojemność węzłów roboczych.
Minimalna konfiguracja wzorcowa
| Rola węzła | Liczba | CPU na węzeł | Pamięć na węzeł | Łączna pojemność |
|---|---|---|---|---|
| Płaszczyzna kontrolna | 3 | 4 vCPU (minimum) | 16 GiB (minimum) | 12 vCPU / 48 GiB |
| Węzły infrastruktury | 3 | ~4 vCPU | ~16 GiB | 12 vCPU / 48 GiB |
| Węzły robocze | 3 | 8 vCPU | 16 GiB | 24 vCPU / 48 GiB / 600 GiB pamięci masowej |
| Łącznie klaster | 9 | - | - | ~48 vCPU / ~144 GiB / 600 GiB pamięci masowej |
Po uwzględnieniu narzutu klastra OpenShift i zasobów zarezerwowanych przez system, konfiguracja z trzema węzłami roboczymi zapewnia wystarczającą dostępną pojemność CPU i pamięci do obsługi produkcyjnego wdrożenia Bob Core.
Więcej informacji można znaleźć w OpenShift Control Plane Sizing Guidelines, Control plane node sizing (utrzymuj wykorzystanie na poziomie 60% lub poniżej dla marginesu HA i aktualizacji) oraz Recommended host practices, Scalability and Performance (zalecane 3 węzły infrastrukturalne).
Wymagania dotyczące pamięci masowej
Bob opiera się na trwałej pamięci masowej dla baz danych, usług wyszukiwania, komponentów cache, konfiguracji, certyfikatów i danych kopii zapasowych. Wybór odpowiedniej klasy pamięci masowej jest ważny dla wydajności i niezawodności.
Konfiguracja wzorcowa przydziela 200 GiB pamięci masowej na węzeł roboczy, co daje łącznie 600 GiB dla całej puli węzłów roboczych. Uwzględnia to wymagania dotyczące trwałych woluminów Bob (~50 GiB), wewnętrzne usługi OpenShift, takie jak rejestr obrazów, monitorowanie i rejestrowanie, oraz pojemność na przyszły wzrost obciążeń.
Obsługiwane klasy pamięci masowej
| Klasa pamięci masowej | Typ | Obsługiwane tryby dostępu |
|---|---|---|
| Zarządzany NFS | Provisionery sieciowego systemu plików (NFS) | RWO, RWX |
| OpenShift Data Foundation (ODF) | Pamięć masowa oparta na Ceph (RBD i CephFS) | RWO, RWX |
Wymagania dotyczące trybu dostępu do pamięci masowej
Różne komponenty Bob wymagają różnych trybów dostępu do pamięci masowej.
| Komponent | Wymagany tryb dostępu | Uwagi |
|---|---|---|
| PostgreSQL | RWO (ReadWriteOnce) | Wymagana pamięć masowa blokowa. Zdecydowanie zalecana pamięć masowa oparta na SSD. |
| OpenSearch | RWO (ReadWriteOnce) | Zalecana wysokowydajna pamięć masowa blokowa. |
| Redis | RWO (ReadWriteOnce) | Trwałe dane wymagają dedykowanego dostępu do odczytu i zapisu. |
| Współdzielona konfiguracja i certyfikaty | RWX (ReadWriteMany) | Wymagane, gdy wiele podów musi jednocześnie montować ten sam wolumin. |
Wydajność pamięci masowej ma znaczący wpływ na responsywność i stabilność Bob on-premises.
Niewystarczająca przepustowość pamięci masowej lub wydajność I/O, szczególnie dla obciążeń PostgreSQL, może powodować wydłużony czas odpowiedzi, wolniejsze operacje indeksowania i ogólnie zdegradowaną wydajność systemu. Wybierając pamięć masową dla obciążeń baz danych:
- Używaj pamięci masowej blokowej opartej na SSD wszędzie tam, gdzie to możliwe.
- Unikaj platform pamięci masowej o wysokich opóźnieniach lub ograniczonych IOPS.
- Zapewnij wystarczającą pojemność na oczekiwany wzrost obciążeń.
- Zweryfikuj wydajność pamięci masowej przed wdrożeniem obciążeń produkcyjnych.
Aby uzyskać optymalną wydajność, wdrażaj woluminy danych PostgreSQL i OpenSearch na najszybszej dostępnej pamięci masowej blokowej w środowisku.
Pamięć masowa kopii zapasowych
Bob wymaga oddzielnego miejsca docelowego pamięci masowej dla operacji tworzenia i przywracania kopii zapasowych. Lokalizacja pamięci masowej kopii zapasowych musi zapewniać wystarczającą pojemność do przechowywania:
- Kopii zapasowych aplikacji
- Kopii zapasowych baz danych
- Migawek indeksów
- Kopii retencyjnych wymaganych przez zasady organizacyjne
Pamięć masowa kopii zapasowych może być dostarczana przez obsługiwane zewnętrzne systemy pamięci masowej, takie jak:
- Udziały Network File System (NFS)
- Repozytoria kopii zapasowych przedsiębiorstwa
- Usługi pamięci masowej obiektowej (jeśli są obsługiwane przez rozwiązanie do tworzenia kopii zapasowych)
Wymagania sieciowe
Komponenty Bob komunikują się wewnętrznie w klastrze OpenShift i zewnętrznie z punktami końcowymi modeli, rejestrami kontenerów, dostawcami LDAP i stacjami roboczymi klientów. Przed instalacją sprawdź, czy wymagana łączność sieciowa i konfiguracja DNS są dostępne.
Upewnij się co najmniej, że:
- Węzły OpenShift mogą się ze sobą komunikować.
- Twoja stacja robocza może uzyskać dostęp do API OpenShift.
- Bob może dotrzeć do skonfigurowanych punktów końcowych LLM.
- Bob może dotrzeć do serwerów LDAP lub Active Directory, jeśli są używane.
- Stacje robocze klientów mogą uzyskać dostęp do punktu końcowego ingress Bob.
- Rekordy DNS są skonfigurowane dla punktu końcowego aplikacji Bob.
- Certyfikaty TLS mogą być weryfikowane ze stacji roboczych klientów.