خوشه های OpenSearch فهرست بندی توزیع شده، جستجو، ذخیره سازی و هماهنگی را با هم ترکیب می کنند. سرورهای خالی به اپراتور کنترل مستقیم روی CPU، حافظه، ذخیره سازی NVMe، رابط های شبکه و سیستم عامل می دهند، اما این کنترل نیاز به طراحی دقیق کلاستر را برطرف نمی کند.
استقرار مناسب فقط سروری با بیشترین هسته یا بزرگترین دیسک نیست. تیم‌ها باید با نرخ جذب، الگوهای درخواست، حفظ، رشد خرده‌ها، بازیابی مدیر خوشه‌ای و اهداف تقسیم‌بندی، داده‌ها، جذب و کار هماهنگی شروع کنند. فلز لخت زمانی ارزشمند است که ورودی/خروجی قابل پیش‌بینی و مالکیت منابع اهمیت داشته باشد، اما خوشه هنوز باید اندازه و به عنوان یک سیستم توزیع شده مدیریت شود.
خوشه OpenSearch برای چیست
OpenSearch ایندکس ها را بین گره ها و بخش ها توزیع می کند. گره‌های واجد شرایط خوشه حالت خوشه را حفظ می‌کنند، گره‌های داده خرده‌ها را ذخیره و بازیابی می‌کنند، و گره‌ها را می‌پذیرند یا هماهنگ می‌کنند می‌توانند کانال‌های سند را مدیریت کنند و درخواست مسیریابی کنند. این نقش‌ها را می‌توان در استقرارهای کوچک‌تر ترکیب کرد، اما جداسازی آنها زمانی مفید می‌شود که فهرست‌بندی، جستجو و هماهنگی خوشه‌ای برای منابع یکسان رقابت کنند.
برای نمای وسیع‌تر از بارهای کاری سنگین، Dataplugs’ Advanced Log Aggregation، SIEM Integration for Hosting توضیح می‌دهد که چرا جمع‌آوری متمرکز، عادی سازی، نمایه‌سازی و حفظ نیاز به زیرساخت‌هایی با اندازه برای ورود و جستجو دارند.
- با پذیرش مدارک، درخواست همزمانی، نگهداری و الزامات بازپرداخت شروع کنید
- از گره های مدیریت خوشه سازگار برای هماهنگی استفاده کنید و زمانی که اندازه خوشه ایجاب می کند آنها را از فشار داده های قابل اجتناب دور نگه دارید.
- از گره‌های داده برای ذخیره‌سازی و جستجو استفاده کنید، با نقش‌های گره که با حجم کار مطابقت دارند نه یک الگوی عمومی
- بخش‌های اولیه، کپی‌ها، و قالب‌های فهرست را به‌عنوان راه‌حل‌های دامنه ظرفیت و خطا در نظر بگیرید
- اندازه NVMe، حافظه و ظرفیت شبکه در اطراف مجموعه کاری، فعالیت‌های تازه‌سازی و ترافیک بازیابی
هنگامی که فلز لخت مناسب تر است
فلز لخت معمولاً زمانی مناسب است که خوشه یک گزارش طولانی یا سقوط رویداد دریافت کند، جستجوهای حساس به تأخیر را انجام دهد، شاخص‌های بزرگی را حفظ کند یا به دسترسی قابل پیش‌بینی به حافظه و NVMe محلی نیاز داشته باشد. منابع تک مشتری نیز توضیح تغییرات عملکرد را آسان‌تر می‌کنند، زیرا گاز CPU، همسایه‌های پر سر و صدا، و اختلاف فضای ذخیره‌سازی غیرشفاف احتمال کمتری دارد که نتیجه را مبهم کند.
OpenSearch به دسترسی به حافظه و فشار پشته حساس است. Dataplugs چرا دانش NUMA در طراحی پایگاه داده و سرور برنامه مهم است؟ توضیح می‌دهد که چگونه CPU و مکان حافظه می‌توانند بر سرویس‌های حافظه فشرده تأثیر بگذارند، از جمله بارهای کاری به سبک Elasticsearch که مشکلات منابع مشابهی دارند.
- زمانی که نمایه سازی و جستجوی انعطاف پذیر باید منابع قابل پیش بینی مشترکی داشته باشند، از سخت افزار اختصاصی استفاده کنید
- از NVMe محلی استفاده کنید وقتی بخش‌هایی که می‌خوانند، بازخوانی می‌کنند، ادغام می‌شوند، عکس‌های فوری یا بازیابی می‌کنند تأخیر ذخیره‌سازی را برای کاربران قابل مشاهده می‌کنند.
- هنگامی که سرویس نیاز به افزونگی، جابجایی قطعه یا مقیاس مستقل جستجو و نمایه سازی دارد، از چندین گره استفاده کنید.
- حافظه را برای کش صفحه سیستم عامل، OpenSearch JVM و فرآیندهای بومی رزرو کنید
- سندی که نمایه‌ها را می‌توان بازسازی کرد، کدام‌ها باید دوباره ساخته شوند، و اینکه بازسازی چقدر طول می‌کشد
زمانی که استقرار کمتر یا مختلط کافی باشد
OpenSearch برای هر موردی به یک خوشه فلزی بزرگ نیاز ندارد. محیط‌های توسعه، تقاضای داخلی با حجم کم و بارهای کاری با تأخیر کوتاه می‌توانند با طرح‌بندی گره ساده‌تر شروع شوند، مشروط بر اینکه تیم از عدم دسترسی بالا و محدودیت‌های یک میزبان واحد آگاه باشد. طراحی تولید باید بر اساس حجم داده های اندازه گیری شده و رفتار پرس و جو باشد، نه یک اندازه خوشه فرضی.
اگر OpenSearch بخشی از یک خط لوله نظارتی یا امنیتی گسترده‌تر است، استفاده از eBPF Dataplugs برای تجزیه و تحلیل بسته‌های عمیق و کشف امنیتی نشان می‌دهد که چگونه تله‌متری در سطح هسته می‌تواند زمینه را به گردش‌های کاری نظارت و کشف با حجم بالا اضافه کند.
- زمانی که حجم داده ها، همزمانی پرس و جو و نیازهای بازیابی واقعاً محدود است، از طرح بندی ساده تر استفاده کنید
- هنگامی که نمایه ها پس از خرابی گره یا دیسک قابل بازیابی هستند، داده های خروجی یا عکس های فوری را در دسترس نگه دارید
- الگوهای شاخص، تجزیه‌کننده‌ها، نگاشت‌ها و خط‌مشی‌های چرخه حیات را در همه محیط‌ها حفظ کنید.
- پس از راه‌اندازی مجدد، یک بوت سرد برنامه‌ریزی کنید، بخش‌ها را جابه‌جا کنید و بازیابی کامل کش را انجام دهید
- از قرار دادن سوابق تجاری غیرقابل جایگزین فقط در فهرست OpenSearch بدون منبع جداگانه و استراتژی پشتیبان خودداری کنید.
نکته: با OpenSearch به عنوان یک موتور جستجو و به عنوان یک سیستم ذخیره سازی توزیع شده رفتار کنید. اگر سندی قابل بازسازی باشد، بازیابی می‌تواند بر میزان مصرف تمرکز کند. اگر این تنها کپی از یک رکورد است، عکس‌های فوری، کپی‌ها و تست بازیابی باید بخشی از طراحی باشد.
نقش های گره و توپولوژی خوشه
یک سرور اختصاصی به هر گره یک مجموعه قابل پیش بینی از محاسبات، حافظه، ذخیره سازی و منابع شبکه می دهد، اما خوشه همچنان به توپولوژی منطبق با مسیر ترافیک نیاز دارد. فشار نمایه‌سازی، انشعاب جستجو، بازیابی خرده‌ها و به‌روزرسانی‌های حالت خوشه‌ای می‌توانند در زمانی که هر گره هر نقشی را حمل می‌کند، با یکدیگر تداخل داشته باشند.
- برای اندازه‌گیری خوشه از نرخ ورودی اندازه‌گیری شده، تأخیر پرس و جو، تعداد بخش‌ها، اندازه قطعه، ادغام بخش‌ها، فشار JVM و واترمارک دیسک استفاده کنید. تعداد زیادی از اسناد به خودی خود اطلاعات کافی نیست. حجم یکسان می‌تواند نیازهای منابع بسیار متفاوتی را بسته به نگاشت فیلد، فواصل بازخوانی، تجمیع‌ها و همزمانی پرس و جو ایجاد کند.
- اندازه CPU برای نمایه سازی، تجزیه، ادغام و اجرای جستجوی همزمان
- پشته JVM را در یک محدودیت عمدی نگه دارید و RAM را برای سیستم عامل و حافظه پنهان سیستم فایل بگذارید.
- استفاده از فضای ذخیره سازی NVMe با کارایی بالا با فضای خالی کافی برای ادغام، کپی کردن، عکس های فوری و بازیابی
- ظرفیت شبکه را برای ترافیک مشتری، انتقال گره به گره، تکثیر و حرکت خرده اندازه گیری کنید
خوشه را با همان نقشه‌برداری‌ها، تجزیه‌کننده‌ها، اندازه‌های سند و ترکیب پرس‌وجو مورد انتظار در تولید آزمایش کنید
ذخیره سازی، خرده ها، کپی ها، و برنامه ریزی شکست
OpenSearch قبل از دریافت تغییرات مربوطه، اسناد را در بخش های اصلی می نویسد. درخواست‌های جستجو را می‌توان توسط کپی‌های اولیه یا خرده‌ای ارائه کرد، بنابراین تعداد خرده‌ها و قرارگیری ماکت‌ها هم بر ظرفیت و هم بر انعطاف‌پذیری تأثیر می‌گذارد. تعداد زیادی قطعات کوچک سربار برای هماهنگی و ابرداده ایجاد می کند. خرده های بزرگ بسیار کم می توانند بازیابی و تعادل را کند کند.
بخش را با در نظر گرفتن رشد شاخص مورد انتظار، تعداد گره های داده، موازی سازی پرس و جو و زمان بازیابی موجود برنامه ریزی کنید. در مواقعی که استادان و کپی‌ها باید به قفسه‌ها، اتاق‌ها یا مکان‌ها جدا شوند، از آگاهی تخصیص یا قوانین قرار دادن معادل استفاده کنید. یک کپی دسترسی را بهبود می بخشد، اما فضای ذخیره سازی، کار نمایه سازی و پهنای باند را برای بازیابی مصرف می کند.
- تعیین کنید که خوشه یک لایه شتاب، یک فروشگاه جستجوی عملیاتی یا یک سیستم ثبت است
- قبل از انتخاب تعداد کپی و فرکانس عکس فوری، نقطه بازیابی و اهداف زمان بازیابی را تنظیم کنید
- تست از دست دادن گره، خستگی دیسک، انتقال بخش، خرابی مدیریت خوشه و بازیابی عکس فوری
- با مسیریابی متعادل، نمایه‌های مبتنی بر زمان، و الگوهای آگاه از بار کاری، از نمایه‌سازی و جستجو در برابر خرده‌های داغ محافظت کنید.
- عکس‌های فوری و کپی‌های بازیابی را خارج از خوشه ناموفق ذخیره کنید و مرتباً بررسی کنید که قابل بازیابی هستند
امنیت، نظارت و استقرار
OpenSearch نباید مستقیماً در معرض اینترنت عمومی قرار گیرد. سرویس های سرویس گیرنده و حمل و نقل را به رابط های خصوصی متصل کنید، قوانین فایروال را محدود کنید، از TLS و کنترل های دسترسی نقش استفاده کنید و دسترسی مدیریت را از ترافیک برنامه جدا کنید. فلز برهنه کنترل این محدودیت ها را به اپراتور می دهد، اما هر پورت و پلاگینی که در معرض دید قرار می گیرد همچنان به یک مالک و یک برنامه پشتیبانی نیاز دارد.
نظارت باید سلامت خوشه را به تأثیر و پذیرش کاربر مرتبط کند. ردیابی پایداری مدیر خوشه، تخصیص خرده، فشار JVM، جمع‌آوری زباله، واترمارک دیسک، تأخیر فهرست، تأخیر جستجو، کار استخر رشته رد شده، ادغام بخش‌ها و پیشرفت بازیابی. سلامت خوشه ممکن است قابل قبول به نظر برسد در حالی که زیرمجموعه‌ای از بخش‌ها یا پرس و جوها در حال وخامت هستند.
- ردیابی نرخ نمایه سازی، تاخیر جستجو، وظایف رد شده، تعداد بخش ها، رشد ذخیره سازی، فشار JVM و رفتار حافظه پنهان
- سیستم های منبع و عوامل سینک را نظارت کنید تا شکاف ناگهانی در گزارش ها با یک خوشه OpenSearch سالم اشتباه گرفته نشود.
- از مستاجرها، نقش ها، مدل های نمایه سازی و سیاست های حفظ جداگانه برای برنامه ها یا محیط های مختلف استفاده کنید
- استقرار نقشه‌ها، به‌روزرسانی‌های افزونه و تغییرات پیکربندی با استقرار مرحله‌ای و مسیر بازگشت
- وصله سند، چرخش گواهی، مالکیت عکس فوری، مسئولیت هشدار، و پاسخ حادثه برای خوشه
نتیجه گیری
میزبانی فلزی برهنه OpenSearch زمانی بهترین کار را انجام می دهد که استقرار آن حول محور حرکت داده ها، رفتار خرده ها و بازیابی فاجعه برنامه ریزی شده باشد، نه فقط مشخصات سرور. CPU، حافظه، NVMe و منابع شبکه قابل پیش‌بینی می‌توانند از جذب و تقاضای پایدار پشتیبانی کنند، اما خوشه همچنان به نقش‌های گره آگاه، محدودیت‌های JVM، تخصیص خرده، کنترل‌های امنیتی و نظارت نیاز دارد.
برای تیم‌هایی که منابع قابل پیش‌بینی را با یک کلاینت برای گره‌های OpenSearch برنامه‌ریزی می‌کنند، راه‌حل‌های سرور اختصاصی Dataplugs گزینه‌های قابل تنظیم CPU، حافظه، ذخیره‌سازی و شبکه را برای استقرار تولید فراهم می‌کنند.
برای اطلاعات بیشتر، به Dataplugs مراجعه کنید یا با sales@dataplugs.com تماس بگیرید.
