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.
Wstępne wartości rozmiarowania dla konfiguracji dodatku Z Understand są teraz opublikowane. Wartości te są oparte na trwających testach porównawczych i mogą zostać zaktualizowane po ich zakończeniu.
Wymagania zawarte w tej sekcji pomagają odpowiednio zaplanować i określić rozmiar środowiska OpenShift.
Obsługiwane wersje
Poniższa tabela zawiera wersje Bob on-premises oraz zgodne wersje komponentów klientów.
| Wersja Bob on-premises | Wersja Bob IDE | Wersja Bob Shell |
|---|---|---|
| 2.0.0 | 2.2.0 | 2.0.5 |
Informacje o zgodności wersji dodatków Premium Package można znaleźć w artykule Zarządzanie uprawnieniami.
Architektura klastra
Instalacja Bob on-premises na OpenShift Container Platform (OCP) obsługuje obecnie następującą architekturę klastra:
amd64(x86_64)
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 | Uwagi |
|---|---|---|
| 4.20 | Przetestowane i obsługiwane | Minimalna obsługiwana wersja |
| 4.21 | Przetestowane i obsługiwane | |
| 4.22 | Przetestowane i obsługiwane |
Rozmiarowanie klastra
Bob działa jako obciążenie tenant na klastrze OpenShift zarządzanym przez klienta. Wymagania dotyczące zasobów różnią się w zależności od wdrożonego stosu Bob. Każda instalacja obejmuje podstawowe komponenty Bob, podczas gdy opcjonalne dodatki Premium Package zwiększają wymagane zasoby procesora, pamięci i pamięci masowej.
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.
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ą.
Obsługiwane konfiguracje stosu
Bob obsługuje wiele konfiguracji wdrożenia. Całkowity ślad zasobów zależy od włączonych dodatków.
| Konfiguracja stosu | CPU (raw) | Pamięć (raw) | Pamięć masowa (PV) | Status |
|---|---|---|---|---|
| Bob Core | 38,1 vCPU | 42,1 GiB | ~50 GiB | Dostępna linia bazowa |
| Bob Core + RAG | 38,1 vCPU | 69,1 GiB | ~62 GiB | Dostępna linia bazowa |
| Bob Core + Z Understand | 30,1 vCPU | 79,1 GiB | ~2288 GiB | Testowanie porównawcze w toku |
| Bob Core + RAG + Z Understand | 46,1 vCPU | 113,1 GiB | ~2320 GiB | Testowanie porównawcze w toku |
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. Wymagania dotyczące zasobów dodatków zostaną opublikowane po zakończeniu testów wydajności.
Ślad zasobów Bob
Następujący wzorcowy ślad dotyczy wdrożenia Bob Core bez włączonych opcjonalnych dodatków.
| Profil wdrożenia | CPU | Pamięć | Pamięć masowa (PV) |
|---|---|---|---|
| Ewaluacja (raw) | 16,8 vCPU | 20,8 GiB | ~9 GiB |
| Ewaluacja (+25–30% marginesu) | ~21 vCPU | ~26 GiB | ~9 GiB |
| Produkcja (raw) | 28,1 vCPU | 41,1 GiB | ~50 GiB |
| Produkcja (+25–30% marginesu) | ~36,5 vCPU | ~53,4 GiB | ~50 GiB |
Zalecane wartości obejmują margines planowania, aby uwzględnić narzut platformy, wahania obciążeń, aktualizacje i przyszły wzrost. Przy określaniu pojemności węzłów roboczych używaj wartości z uwzględnionym marginesem.
Klaster Single Node OpenShift (SNO)
Single Node OpenShift łączy płaszczyznę kontrolną i obciążenia robocze na jednym hoście. Wdrożenia SNO są odpowiednie dla środowisk proof-of-concept, deweloperskich, testowych i brzegowych, gdzie wysoka dostępność nie jest wymagana.
Wzorcowe rozmiarowanie
| Warstwa | CPU | Pamięć | Pamięć masowa |
|---|---|---|---|
| Minimum platformy OpenShift | 8 vCPU | 16 GiB | 120 GiB |
| Obciążenie ewaluacyjne Bob (z marginesem) | ~21 vCPU | ~26 GiB | ~9 GiB |
| Wzorzec węzła łącznie | ~29 vCPU | ~42 GiB | ~130 GiB |
- Single Node OpenShift nie zapewnia redundancji węzłów.
- Obciążenia płaszczyzny kontrolnej i aplikacji współdzielą ten sam host.
- Awaria węzła powoduje całkowitą niedostępność usługi.
- SNO nie jest zalecane dla środowisk produkcyjnych wymagających dostępności lub możliwości odzyskiwania po awarii.
Wskazówki dotyczące instalacji można znaleźć w artykule How to install single node OpenShift on bare metal (minimum 8 vCPU / 16 GiB RAM / 120 GiB pamięci masowej) oraz Preparing to install on a single node, OCP 4.20.
Klaster wielowęzłowy OpenShift
Poniższa architektura przedstawia minimalną wzorcową konfigurację wdrożenia Bob działającego w dedykowanym klastrze.
Minimalna konfiguracja wzorcowa
| Rola węzła | Liczba | CPU na węzeł | Pamięć na węzeł | Zasoby łącznie |
|---|---|---|---|---|
| Płaszczyzna kontrolna | 3 | 4 vCPU | 16 GiB | 12 vCPU / 48 GiB |
| Infrastruktura | 3 | ~4 vCPU | ~16 GiB | 12 vCPU / 48 GiB |
| Roboczy | 3 | 20 vCPU | 24 GiB | 60 vCPU / 72 GiB / 600 GiB pamięci masowej |
| Łącznie klaster | 9 | - | - | ~84 vCPU / ~168 GiB / 600 GiB |
Po uwzględnieniu narzutu OpenShift, pula węzłów roboczych zapewnia około:
- 57 vCPU pojemności do alokacji
- 63 GiB pamięci do alokacji
Ta pojemność jest wystarczająca do obsługi produkcyjnego śladu Bob Core, w tym zalecanego marginesu planowania:
| Wymaganie | CPU | Pamięć |
|---|---|---|
| Wymaganie produkcyjne Bob Core | ~36,5 vCPU | ~53,4 GiB |
| Pojemność do alokacji puli węzłów roboczych | ~57 vCPU | ~63 GiB |
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 | Status |
|---|---|---|---|
| Zarządzany NFS | Provisionery sieciowego systemu plików (NFS) | RWO, RWX | Obsługiwane |
| OpenShift Data Foundation (ODF) | Pamięć masowa oparta na Ceph (RBD i CephFS) | RWO, RWX | Obsługiwane |
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.