راهاندازی کلاستر Elasticsearch با Ansible روی چند سرور مجازی و اختصاصی: نقش گرهها، TLS و مدیریت چرخه عمر ایندکس (ILM)
وقتی حجم لاگ، رویدادهای برنامه و دادههای جستوجو افزایش پیدا میکند، اجرای Elasticsearch روی یک سرور به نقطهضعف تبدیل میشود. خرابی همان سرور، کل سرویس جستوجو را از دسترس خارج میکند و نگهداری دستی تنظیمات نیز بین محیطها اختلاف ایجاد میکند. راهاندازی کلاستر Elasticsearch با Ansible این فرایند را تکرارپذیر میکند؛ یعنی میتوانید چند گره را با یک مجموعه متغیر و playbook ایجاد، امن و بهروزرسانی کنید.
در این راهنما یک معماری نمونه برای ترکیب سرورهای مجازی و اختصاصی میسازیم. نقش گرهها را جدا میکنیم، ارتباطات را با TLS رمزنگاری میکنیم و با Index Lifecycle Management یا ILM، هزینه ذخیرهسازی را کنترل خواهیم کرد. مثالها برای Elasticsearch نسخه ۸ نوشته شدهاند؛ نام بعضی تنظیمات در نسخههای قدیمیتر متفاوت است.
طراحی معماری کلاستر
پیش از نوشتن playbook، باید مشخص کنید هر گره چه کاری انجام میدهد. در Elasticsearch جدید، نقشها با پارامتر node.roles تعیین میشوند. برای محیط تولیدی معمولاً سه گره master-eligible و چند گره data لازم است. تعداد masterها باید فرد باشد تا در زمان قطع ارتباط، اکثریت کلاستر بتواند تصمیم بگیرد.
یک چیدمان عملی میتواند چنین باشد:
- سه گره master کوچک، برای نگهداری وضعیت کلاستر و انتخابات.
- دو یا چند گره data با دیسک NVMe یا SSD، برای ذخیره شاردها و اجرای جستوجو.
- یک یا چند گره ingest یا coordinating، در صورت سنگین بودن پردازش ورودی و درخواستهای کلاینت.
- یک ماشین جدا برای Ansible و نگهداری امن دسترسی متغیرها.
سرورهای اختصاصی برای گرههای data با بار نوشتن زیاد مناسباند، چون دیسک سریع و حافظه بیشتری در اختیار دارید. گرههای master به CPU و دیسک بسیار قدرتمند نیاز ندارند، اما باید تأخیر شبکه کمی با یکدیگر داشته باشند. گرههای مجازی نیز برای master یا coordinating گزینه مناسبی هستند، به شرط آنکه منابع آنها بیش از حد اشتراکی و ناپایدار نباشد.
نمونه مقایسه نقشها
| نقش گره | منابع پیشنهادی | وظیفه اصلی | نکته عملیاتی |
|---|---|---|---|
| master-eligible | ۲ تا ۴ vCPU، رم ۸ تا ۱۶ گیگابایت | مدیریت متادیتا و انتخابات | سه گره مستقل در دسترسپذیری بالا |
| data_hot | CPU و رم بالا، SSD/NVMe | دادههای تازه و پرترافیک | مناسب جستوجوی سریع و ingest |
| data_warm | منابع متوسط، دیسک پرظرفیت | دادههای کمتغییر | هزینه کمتر برای دادههای قدیمیتر |
| ingest | CPU بیشتر | تبدیل و غنیسازی اسناد | فقط در صورت نیاز به pipeline سنگین |
| coordinating | منابع متناسب با ترافیک | پخش درخواست و جمعکردن پاسخ | برای جدا کردن کلاینتها از data |
برای جلوگیری از split-brain، مقدار discovery.seed_hosts را به آدرس هر سه master بدهید و cluster.initial_master_nodes را فقط در نخستین راهاندازی تنظیم کنید. بعد از تشکیل کلاستر، این گزینه را از پیکربندی دائمی حذف کنید؛ باقی ماندن آن در بازراهاندازیهای بعدی میتواند دردسر ایجاد کند.
آمادهسازی سیستمعامل با Ansible
در inventory، گروهها را از نقش واقعی جدا کنید تا بتوانید یک گره را بدون کپیکردن فایلها تغییر دهید؛ همین ساختار در اتوماسیون پیکربندی چند سرور با Ansible هم بهکار میرود:
```ini
