Configurați Amazon OpenSearch Service pentru disponibilitate ridicată | Amazon Web Services

Serviciul Amazon OpenSearch este un motor de căutare și analiză complet open-source care deblochează în siguranță căutarea, monitorizarea și analiza în timp real a datelor de afaceri și operaționale pentru cazuri de utilizare precum motoarele de recomandare, site-urile de comerț electronic și căutarea în catalog. Pentru a avea succes în afacerea dvs., aveți nevoie ca sistemele dvs. să fie foarte disponibile și performante, minimizând timpul de nefuncționare și evitând eșecurile. Când utilizați Serviciul OpenSearch ca mijloc principal de monitorizare a infrastructurii, trebuie să vă asigurați și disponibilitatea acesteia. Timpul de nefuncționare pentru serviciul OpenSearch poate avea un efect semnificativ asupra rezultatelor afacerii dvs., cum ar fi pierderea veniturilor, pierderea productivității, pierderea valorii mărcii și multe altele.

standard industrial pentru măsurarea disponibilității este clasa nouă. Serviciul OpenSearch oferă 3 9 de disponibilitate, atunci când urmăriți Cele mai bune practici, ceea ce înseamnă că garantează mai puțin de 43.83 minute de oprire pe lună. În această postare, veți afla cum vă puteți configura domeniul serviciului OpenSearch pentru disponibilitate și performanță ridicate, urmând cele mai bune practici și recomandări în timp ce vă configurați domeniul.

Există două elemente esențiale care influențează disponibilitatea domeniului dvs.: utilizarea resurselor domeniului dvs., care este determinată în principal de volumul dvs. de lucru, și evenimente externe, cum ar fi defecțiunile infrastructurii. Deși primul poate fi controlat prin monitorizarea continuă a performanței și sănătății domeniului și scalarea domeniului în consecință, cel de-al doilea nu poate. Pentru a atenua impactul evenimentelor externe, cum ar fi o întrerupere a zonei de disponibilitate, o defecțiune a instanței sau a discului sau problemele de rețea pe domeniul dvs., trebuie să furnizați capacitate suplimentară, distribuită în mai multe zone de disponibilitate și să păstrați mai multe copii ale datelor. Nerespectarea acestui lucru poate duce la o performanță redusă, indisponibilitate și, în cel mai rău caz, pierderea datelor.

Să ne uităm la opțiunile disponibile pentru a ne asigura că domeniul este disponibil și performant.

Configurare cluster

În această secțiune vom vorbi despre diferite opțiuni de configurare pe care le aveți pentru a configura clusterul în mod corespunzător, care include specificarea numărului de AZ pentru implementare, configurarea nodurilor master și de date, configurarea indexurilor și shard-urilor.

Implementare multi-AZ

Nodurile de date sunt responsabile pentru procesarea cererilor de indexare și căutare în domeniul dvs. Implementarea nodurilor de date în mai multe zone de disponibilitate îmbunătățește disponibilitatea domeniului dvs. prin adăugarea de stocare și procesare redundante a datelor pe zonă. Cu o implementare Multi-AZ, domeniul dvs. poate rămâne disponibil chiar și atunci când o zonă de disponibilitate completă devine indisponibilă. Pentru sarcinile de producție, AWS recomandă utilizarea a trei zone de disponibilitate pentru domeniul dvs. Utilizați două zone de disponibilitate pentru regiuni care acceptă doar două pentru o disponibilitate îmbunătățită. Acest lucru vă asigură că domeniul dvs. este disponibil în cazul unei erori Single-AZ.

Manager de cluster dedicat (noduri master)

AWS recomandă utilizarea a trei noduri dedicate de manager de cluster (CM). pentru toate sarcinile de producție. Nodurile CM urmăresc starea clusterului, starea și locația indexurilor și fragmentelor acestuia, maparea pentru toți indecșii și disponibilitatea nodurilor sale de date și menține o listă de sarcini la nivel de cluster în proces. Fără noduri CM dedicate, clusterul folosește noduri de date, ceea ce face clusterul vulnerabil la cerințele de sarcină de lucru. Ar trebui să dimensionați nodurile CM în funcție de dimensiunea sarcinii - în primul rând, numărul de noduri de date, numărul de index și numărul de fragmente. Serviciul OpenSearch implementează întotdeauna noduri CM în trei zone de disponibilitate, atunci când este acceptat de regiune (două într-o zonă de disponibilitate și una în alte zone de disponibilitate dacă regiunile au doar două zone de disponibilitate). Pentru un domeniu care rulează, doar unul dintre cele trei noduri CM funcționează ca lider ales. Celelalte două noduri CM participă la o alegere dacă nodul CM ales eșuează.

Următorul tabel prezintă recomandările AWS pentru dimensionarea CM. Nodurile CM funcționează pe baza numărului de noduri, indici, fragmente și cartografiere. Cu cât mai multă muncă, cu atât mai multă calcul și memorie aveți nevoie pentru a păstra și a lucra cu starea clusterului.

Număr de instanțe	Dimensiunea RAM al nodului Cluster Manager	Numărul maxim de fragmente acceptat	Tipul de instanță minim recomandat pentru Managerul de clustere dedicat
1-10	8 GiB	10,000	m5.large.search sau m6g.large.search
11-30	16 GiB	30,000	c5.2xlarge.search sau c6g.2xlarge.search
31-75	32 GiB	40,000	c5.4xlarge.search sau c6g.4xlarge.search
76 - 125	64 GiB	75,000	r5.2xlarge.search sau r6g.2xlarge.search
126 - 200	128 GiB	75,000	r5.4xlarge.search sau r6g.4xlarge.search

Indici și cioburi

Indecii sunt o construcție logică care adăpostește o colecție de documente. Partiționați indexul pentru procesare paralelă prin specificarea unui număr de fragmente primare, unde fragmentele reprezintă o unitate fizică pentru stocarea și procesarea datelor. În Serviciul OpenSearch, un fragment poate fi fie un fragment primar, fie un fragment replica. Folosiți replici pentru durabilitate - dacă fragmentul principal este pierdut, OpenSearch Service promovează una dintre replici la primară - și pentru îmbunătățirea debitului de căutare. Serviciul OpenSearch asigură că fragmentele primare și replica sunt plasate în noduri diferite și în diferite zone de disponibilitate, dacă sunt implementate în mai multe zone de disponibilitate. Pentru o disponibilitate ridicată, AWS recomandă configurarea a cel puțin două replici pentru fiecare index într-o configurare cu trei zone pentru a evita întreruperea performanței și a disponibilității. Într-o configurare Multi-AZ, dacă un nod eșuează sau, în cel mai rar caz, o zonă de disponibilitate eșuează, veți avea în continuare o copie a datelor.

Monitorizarea și managementul clusterelor

După cum sa discutat mai devreme, selectarea configurației pe baza celor mai bune practici este doar jumătate din treabă. De asemenea, trebuie să monitorizăm în mod continuu utilizarea resurselor și performanța pentru a determina dacă domeniul trebuie să fie scalat. Un domeniu subprovizionat sau suprautilizat poate duce la degradarea performanței și, în cele din urmă, la indisponibilitate.

Utilizarea procesorului

Utilizați procesorul din domeniul dvs. pentru a vă rula volumul de lucru. Ca regulă generală, ar trebui să vizați o utilizare medie a CPU de 60% pentru orice nod de date, cu vârfuri la 80% și să tolerați vârfuri mici până la 100%. Când luați în considerare disponibilitatea, și mai ales având în vedere indisponibilitatea unei zone complete, există două scenarii. Dacă aveți două zone de disponibilitate, atunci fiecare zonă gestionează 50% din trafic. Dacă o zonă devine indisponibilă, cealaltă zonă va prelua tot acel trafic, dublând utilizarea CPU. În acest caz, trebuie să fiți la aproximativ 30–40% de utilizare medie a procesorului în fiecare zonă pentru a menține disponibilitatea. Dacă rulați trei zone de disponibilitate, fiecare zonă ocupă 33% din trafic. Dacă o zonă devine indisponibilă, fiecare zonă va câștiga aproximativ 17% trafic. În acest caz, ar trebui să vizați o utilizare medie a procesorului de 50–60%.

Utilizarea memoriei

OpenSearch Service acceptă două tipuri de colectare a gunoiului. Primul este G1 garbage collection (G1GC), care este folosit de nodurile OpenSearch Service, alimentat de AWS Graviton 2. Al doilea este Concurrent Mark Sweep (CMS), care este utilizat de toate nodurile alimentate de alte procesoare. Din toată memoria alocată unui nod, jumătate din memorie (până la 32 GB) este alocată heap-ului Java, iar restul memoriei este utilizată de alte sarcini ale sistemului de operare, cache-ul sistemului de fișiere și așa mai departe. Pentru a menține disponibilitatea pentru un domeniu, vă recomandăm să mențineți utilizarea maximă a JVM la aproximativ 80% în CMS și 95% în G1GC. Orice altceva dincolo de aceasta ar afecta disponibilitatea domeniului dvs. și ar face clusterul dvs. nesănătos. De asemenea, vă recomandăm să activați reglarea automată, care monitorizează în mod activ utilizarea memoriei și declanșează colectorul de gunoi.

Utilizarea depozitului

OpenSearch Service publică mai multe linii directoare pentru dimensionarea domeniilor. Oferim o formulă empirică, astfel încât să puteți determina cantitatea potrivită de stocare necesară pentru cerințele dumneavoastră. Cu toate acestea, este important să fiți atenți la epuizarea spațiului de stocare odată cu timpul și la modificările caracteristicilor încărcăturii de lucru. Pentru a vă asigura că domeniul nu rămâne fără spațiu de stocare și că poate continua să indexeze datele, ar trebui să configurați Amazon CloudWatch alarme și monitorizați spațiul de stocare gratuit.

AWS recomandă, de asemenea, alegerea unui număr de fragmente primare, astfel încât fiecare fragment să fie într-o bandă de dimensiune optimă. Puteți determina dimensiunea optimă a fragmentului prin testarea dovadă a conceptului cu datele și traficul dvs. Folosim dimensiunile fragmentelor primare de 10–30 GB pentru cazurile de utilizare de căutare și dimensiunile fragmentelor primare de 45–50 GB pentru cazurile de utilizare a analizei jurnalului ca ghid. Deoarece fragmentele sunt lucrătorii din domeniul dvs., ele sunt direct responsabile pentru distribuția volumului de lucru între nodurile de date. Dacă fragmentele dvs. sunt prea mari, este posibil să observați stres în heap-ul dvs. Java din cauza agregărilor mari, performanță mai slabă a interogărilor și performanță mai slabă la sarcinile la nivel de cluster, cum ar fi reechilibrarea fragmentelor, instantanee și migrări de la cald la cald. Dacă fragmentele dvs. sunt prea mici, ele pot copleși spațiul heap Java al domeniului, pot înrăutăți performanța interogărilor prin intermediul unei rețele interne excesive și pot încetini sarcinile la nivel de cluster. Vă recomandăm, de asemenea, să păstrați numărul de fragmente pe nod proporțional cu heap-ul disponibil (jumătate din memoria RAM a instanței de până la 32 GB) — 25 de fragmente per GB de heap Java. Acest lucru face o limită practică de 1,000 de fragmente pe orice nod de date din domeniul dvs.

Concluzie

În această postare, ați învățat diverse sfaturi și trucuri pentru a configura un domeniu foarte disponibil utilizând OpenSearch Service, care vă ajută să mențineți OpenSearch Service performant și disponibil, rulându-l în trei zone de disponibilitate.

Rămâneți pe fază pentru o serie de postări care se concentrează pe diferitele caracteristici și funcționalități ale serviciului OpenSearch. Dacă aveți feedback despre această postare, trimiteți-l în secțiunea de comentarii. Dacă aveți întrebări despre această postare, începeți un nou thread pe Forumul OpenSearch Service sau contact Asistență AWS.

---

Despre autori

Rohin Bhargava este manager de produs senior cu echipa Amazon OpenSearch Service. Pasiunea lui la AWS este de a ajuta clienții să găsească combinația corectă de servicii AWS pentru a atinge succesul pentru obiectivele lor de afaceri.

Prashant Agrawal este un arhitect specialist în soluții de căutare cu Amazon OpenSearch Service. El lucrează îndeaproape cu clienții pentru a-i ajuta să-și migreze sarcinile de lucru în cloud și îi ajută pe clienții existenți să-și ajusteze clusterele pentru a obține performanțe mai bune și a economisi costuri. Înainte de a se alătura AWS, el a ajutat diverși clienți să folosească OpenSearch și Elasticsearch pentru cazurile de utilizare a analizei de căutare și jurnal. Când nu lucrează, îl poți găsi călătorind și explorând locuri noi. Pe scurt, îi place să facă Eat → Travel → Repeat.

• Distribuție de conținut bazat pe SEO și PR. Amplifică-te astăzi.
• PlatoAiStream. Web3 Data Intelligence. Cunoștințe amplificate. Accesați Aici.
• Mintând viitorul cu Adryenn Ashley. Accesați Aici.
• Cumpărați și vindeți acțiuni în companii PRE-IPO cu PREIPO®. Accesați Aici.
• Sursa: https://aws.amazon.com/blogs/big-data/configure-amazon-opensearch-service-for-high-availability/