Wdrażanie klastra bazy danych MongoDB w usłudze Azure Kubernetes Service (AKS)

W tym artykule przedstawiono informacje dotyczące wymagań wstępnych dotyczących wdrażania klastra Bazy danych MongoDB w usłudze Azure Kubernetes Service (AKS). Zawiera również omówienie strategii wdrażania.

Ważne

Oprogramowanie typu open source jest wymienione w dokumentacji i przykładach usługi AKS. Wdrażane oprogramowanie jest wykluczone z umów dotyczących poziomu usług AKS, ograniczonej gwarancji i pomoc techniczna platformy Azure. W miarę korzystania z technologii open source wraz z usługą AKS zapoznaj się z opcjami pomocy technicznej dostępnymi w odpowiednich społecznościach i opiekunami projektów, aby opracować plan.

Na przykład repozytorium Ray GitHub opisuje kilka platform, które różnią się w czasie odpowiedzi, celu i poziomie pomocy technicznej.

Firma Microsoft ponosi odpowiedzialność za tworzenie pakietów typu open source wdrażanych w usłudze AKS. Ta odpowiedzialność obejmuje posiadanie pełnej własności procesu kompilacji, skanowania, podpisywania, weryfikowania i poprawek oraz kontroli nad plikami binarnymi na obrazach kontenerów. Aby uzyskać więcej informacji, zobacz Zarządzanie lukami w zabezpieczeniach dla usług AKS i pokrycie pomocy technicznej usługi AKS.

Co to jest mongoDB?

MongoDB to popularny system zarządzania bazami danych NoSQL, który jest przeznaczony do obsługi dużych ilości danych bez struktury. W przeciwieństwie do tradycyjnych relacyjnych baz danych korzystających z tabel i wierszy baza danych MongoDB korzysta z elastycznego, zorientowanego na dokument podejścia.

Uwaga

Program MongoDB Community Edition nie jest oprogramowaniem typu open source. Licencjonowany jest w ramach licencji publicznej po stronie serwera z "dostępnym źródłem".

Klaster podzielony na fragmenty bazy danych MongoDB

Klaster podzielony na fragmenty bazy danych MongoDB obsługuje duże zestawy danych i wysoką przepływność, dystrybuując dane na wielu serwerach lub fragmentach. Ta architektura umożliwia skalowanie w poziomie, co jest niezbędne w przypadku aplikacji, które mają rosnące potrzeby w zakresie danych i wydajności.

Poniżej przedstawiono podział kluczowych składników i sposób jego działania:

• Fragmenty: pojedyncze wystąpienia bazy danych MongoDB nazywane fragmentami przechowują podzestawy danych. Każdy fragment jest zestawem replik lub grupą wystąpień bazy danych MongoDB, które replikują dane samodzielnie. Zestawy replik pomagają zapewnić wysoką dostępność i odporność na uszkodzenia.
• Serwery konfiguracji: serwery przechowujące metadane i ustawienia konfiguracji dla klastra podzielonego na fragmenty są nazywane serwerami konfiguracji. Śledzą one dystrybucję danych klastra i informacje o routingu. Klaster zwykle ma trzy serwery konfiguracji w celu zapewnienia nadmiarowości.
• Wystąpienia mongos: Mongos to usługa routingu, która kieruje żądania klientów do odpowiedniego fragmentu. Działa jako pośrednik między klientem a fragmentami. Wystąpienie bazy danych Mongos zarządza routingiem zapytań i agreguje wyniki z fragmentów.
• Klucz fragmentu: gdy dane są dystrybuowane między fragmenty, są oparte na kluczu fragmentu, który jest pojedynczym polem indeksowanym lub wieloma polami w dokumentach. Klucz fragmentu określa sposób partycjonowania danych między fragmentami. Dobrze wybrany klucz fragmentu pomaga zapewnić równomierną dystrybucję danych i wydajne wykonywanie zapytań.
• Dystrybucja danych: dane są dystrybuowane między fragmentami na podstawie klucza fragmentu. Ta dystrybucja pomaga efektywnie równoważyć obciążenie i zarządzać dużymi zestawami danych. Baza MongoDB używa strategii fragmentowania opartej na zakresie lub skrótu w zależności od klucza fragmentu.
• Wysoka dostępność: każdy fragment jest zestawem replik, co oznacza, że replikuje swoje dane między wieloma węzłami. Ta konfiguracja gwarantuje, że dane pozostają dostępne nawet wtedy, gdy co najmniej jeden węzeł ulegnie awarii.

Operator Percona dla bazy danych MongoDB

Operator Percona dla bazy danych MongoDB to narzędzie typu open source opracowane przez platformę Percona . Automatyzuje wdrażanie, zarządzanie i skalowanie klastrów MongoDB w środowiskach Kubernetes. Upraszcza ona operacje, obsługując zadania, takie jak aprowizowanie, skalowanie, tworzenie kopii zapasowych i odzyskiwanie. Obsługa wszystkich tych zadań pomaga zapewnić wysoką dostępność i wydajność klastrów MongoDB.

Operator używa niestandardowych definicji zasobów platformy Kubernetes (CRD) do deklaratywnego zarządzania konfiguracjami bazy danych MongoDB oraz do obsługi trybu failover, monitorowania i alertów. Rezultatem jest zmniejszenie nakładu pracy administracyjnej i spójne rozwiązania w zakresie zarządzania. Operator Percona zwiększa wydajność i niezawodność wdrożeń bazy danych MongoDB, szczególnie w aplikacjach natywnych dla chmury. Idealnie nadaje się do scenariuszy tworzenia, testowania i produkcji.

Omówienie rozwiązania MongoDB

Celem proponowanego rozwiązania jest:

• Upewnij się, że klaster Bazy danych MongoDB może efektywnie obsługiwać duże zestawy danych i operacje o wysokiej przepływności.
• Zachowaj wysoką dostępność i odporność na uszkodzenia.

Rozwiązanie pozwoli osiągnąć ten cel za pomocą zestawów replik, reguł anty-koligacji i prawidłowej alokacji zasobów.

Strategia wdrażania

Strategia wdrażania bazy danych MongoDB składa się z następujących składników:

• Klaster podzielony na fragmenty umożliwiający dystrybucję danych między wieloma fragmentami, zwiększając skalowalność i wydajność.
• Serwery konfiguracji zarządzane przez zestaw replik z trzema elementami członkowskimi, aby zapewnić odporność na uszkodzenia i wysoką dostępność. Reguły ochrony przed koligacją dystrybuują te serwery między domenami błędów.
• Trzy wystąpienia bazy danych Mongos rozproszone między strefami dostępności i uwidocznione wewnętrznie w klastrze. Zapewniają one równoważenie obciążenia i odporność na kierowanie żądań klientów.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy pierwotnie to napisali:

• Nelly Kiboi | Inżynier usługi
• Saverio Proto | Główny inżynier środowiska klienta
• Don High | Główny inżynier klienta
• LaBrina Loving | Główny inżynier usługi
• Ken Kilty | Moduł TPM podmiotu zabezpieczeń
• Russell de Pina | Moduł TPM podmiotu zabezpieczeń
• Colin Mixon | Menedżer produktu
• Ketan Chawda | Starszy inżynier klienta
• Naveed Kharadi | Inżynier środowiska klienta
• Erin Schaffer | Content Developer 2
• Carol Smith | Starszy deweloper zawartości

Następny krok

Tworzenie zasobów infrastruktury na potrzeby uruchamiania klastra bazy danych MongoDB w usłudze AKS