در مسیر Observability، جمع بندی استک الک (قسمت سوم)

توی قسمت سوم مسیر Observability کامپوننت هایی که از استک الک مونده بود رو بررسی میکنم، یه مقایسه بین fluentd و fluentbit انجام میدیم و نهایتا یه توضیح مختصر در مورد Opensearch و Elastic Cloud.

خب یه مروری کنیم پست‌های قبلی رو:

• دواپس چیه و چرا لازمه؟  اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.

• چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.

• چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.

• خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.

• در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.

• در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.

• در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.

• تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.

• در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.

• در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.

• در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.

• در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.

• در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.

• در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.

• در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.

• در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.

• در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.

• در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.

• در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.

• در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیم

• در مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.

• آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.

• کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.

• کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.

• پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.

• ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.

• اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.

• نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.

• استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.

• پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.

• پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.

• اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.

• کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.

• دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.

• مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.

• هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.

• سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.

• نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.

• نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.

• نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.

توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.

خب بریم که بقیه موارد استک الک رو با هم بررسی کنیم:

Kibana:

یه اینترفیس browser-based که میتونه برای سرچ آنالیز و مهم تر از همه visualize کردن دیتای ذخیره شده توی الستیک سرچ استفاده بشه. کیبانا اوپن سورس هست و با بقیه دیتابیس ها هم سازگار نیست. کیبانا میتونه بهمون توی منیج کردن دیتا و مانیتور کردن وضعیت کلاستر الستیک و کنترل کردن اینکه چه یوزرهایی به چه قابلیت هایی دسترسی دارن کمک کنه. تو آنالیز دیتا کیبانا کمک میکنه تا با استفاده از چارت ها و نقشه ها و گراف هایی که از ترکیب دیتا می‌کشیم بتونیم درک بهتری رو از طریق داشبورد کیبانا بدست بیاریم. کیبانا حتی توی آنالیز لاگ ها برای پیدا کردن آسیب‌پذیری‌های امنیتی هم بهمون کمک میکنه و یه جورایی درگاه دسترسی ما به این قابلیت‌ها هست. ما با استفاده از kibana می‌تونیم هم استک خودمون رو کانفیگ کنیم و هم به خوبی query بزنیم و مواردی که داریم رو مشاهده کنیم.

Beats:

بهشون اصطلاحا میگن log shipper، کامپوننت‌های سبکی که به زبان گولنگ توسعه یافتن تا به عنوان ایجنت توی محیط‌های مختلف بتونن با مصرف کم منابع و بدون دیپندنسی نصب بشن تا لاگ ها و متریک ها رو جمع آوری کنند. البته دیگه فقط لاگ نیست که می‌تونه متریک‌ها و موارد دیگه رو هم برای ما به سمت استک ELK که راه‌اندازی کردیم ارسال کنه. در ادامه لیستی از انواع Beats رو براتون میذارم و یه توضیح مختصر که هر کدومش چه دیتایی رو جمع آوری میکنه :

• Filebeat: Filebeat is used for collecting and shipping log files.

• Packetbeat: A network packet analyzer, Packetbeat was first beat introduced. Packetbeat captures network traffic between servers, and such can be used for application and performance monitoring.

• Metricbeat: Metricbeat collects ships various system-level metrics for various system and platforms.

• Winlogbeat: Winlogbeat will only interest Windows sysadmins or engineers as it is a beat designed specifically for collecting Windows Event logs.

• Auditbeat: Auditbeat can be used for auditing user and process activity on your linux servers.

• Functionbeat: Functionbeat is defined as a serverless shipper that can be deployed as a function to collect and ship data into the ELK Stack.

بنابراین Beats اولین راهی هست که استک ELK برای فرستادن دیتا سمت انجین اصلی استک داره و بسته به اینکه چه دیتایی رو میخوایم جمع کنیم باید تعدادی Beats رو نصب کنیم رو هاست‌مون که شاید اگر تمام موارد رو نیاز داشته باشیم بهینه نباشه. برای همین کانسپت دیگه‌ای به اسم elastic agent وجود داره که این موضوع رو خیلی بهینه‌تر هندل می‌کنه و به زبان ساده راه‌ حل این مشکل هست.

Elastic Agent:

راه دوم و جدیدتر استک ELK برای فرستادن دیتا سمت الستیک استفاده از الستیک ایجنت هست که برای لاگ، متریک و دیتای سکیوریتی و … ازش استفاده میکنیم. الستیک ایجنت رو میتونیم به دو روش دیپلوی کنیم. روش اول standalone mode هست که همه‌ی پالیسی هامون رو به صورت دستی در قالب یک فایل yaml قرار می‌دیم، که این روش یه مقدار پیچیده تر هست و برای جاهایی که agent ما در محیط ایزوله‌ای قرار داره و بهش دسترسی نیست توصیه میشه. یه جورایی داریم کانفیگ هر agent رو داخل خودش انجام می‌دیم.

اما روش دوم دیپلوی الستیک ایجنت فلیت هست. ایجنت پالیسی‌ها و لایف سایکل میتونه به صورت مرکزی با استفاده از اپ فلیت توی کیبانا منیج بشه که این روشی هست که برای اکثر کاربران توصیه میشه. این روش خیلی بهینه است و به محضی که تغییری در کانفیگ‌‌ها و پالیسی‌های agent ایجاد کنیم به صورت مرکزی روی تمام agentها اعمال می‌شه و خیلی خیلی بهینه است. می‌تونم بگم قدرت روش جدید توی همین fleet هست که می‌تونیم agentهای خودمون رو به صورت مرکزی مدیریت و کانفیگ کنیم.

Fleet Server:

کامپوننتی که ایجنت های الستیک رو به فلیت متصل میکنه، فلیت سرور هست و همزمان به چندین ایجنت وصل می‌شه و به عنوان یه کنترل پلین پالیسی‌های اونها رو آپدیت می‌کنه و دیتای وضعیت اونها رو جمع آوری می‌کنه. همچنین قابلیت یک ساختار اسکیل‌پذیر رو بهمون میده و با اضافه شده تعداد و سایز ایجنت‌های الستیک می‌تونیم فلیت سرورها رو هم بیشتر کنیم تا بتونیم لود بیشتر رو هم هندل کنیم. از اونجا که فلیت سرور stateless هست و اصلا کلا توی استک ELK فقط elasticserach هست که stateful هست، میتونیم روی فلیت سرورها لود بالانس انجام بدیم و به صورت افقی آنها را زیاد کنیم.

در ادامه دو تا ابزار دیگه بهتون معرفی می‌کنم که تو این استک نیستن ولی اونقدر کنار اینها تعریف می‌شن و جایگزین‌های محبوبی هستند که گاها به جای ELK ما از EFK استفاده می‌کنیم که fluentd رو با logstash جایگزین می‌کنیم. بریم ببینیم چی هست و چه کاری برای ما انجام می‌دهند.

Fluentd:

ابزار اوپن سورسی برای جمع آوری لاگ از منابع مختلف و فرستادن اونها به مقصدها مختلف که توی سال ۲۰۱۱ Treasure Data اون رو توسعه داد. بالای هزار تا پلاگین مختلف داره که میتونه از سورس‌ها و دستینیشن‌های مختلف پشتیبانی کنه که همین انعطاف‌پذیری هم نقطه قوت این ابزار هست. فلوئنت‌دی به زبان سطح بالای روبی توسعه یافته تا بتونه کامیونیتی بیشتری رو برای مشارکت داشته باشه. با مکانیزم بافرینگی که داره میتونه حتی موقع تولید لاگ سنگین هم بدون دیتا لاس کار کنه که این ویژگی اون رو قابل اتکاتر میکنه. این پایداری که فلوئنت‌دی ارائه میده باعث شده تا کمپانی‌های زیادی بهش اعتماد کنن و کلا استک EFK رو داریم که جای لاگ استش از فلوئنت‌دی استفاده میشه برای فیلتر و بافر و روتیت کردن لاگ.

Fluent bit:

ابزار دیگه ای که توسط تیم Treasure Data توسعه یافته به زبان C برای جمع آوری لاگ. سبک بودن و استفاده بهینه از منابع ویژگی اصلی این ابزار هست و با بیش از ۱۰۰ پلاگینی که داره میتونه با ساختار های متنوعی ادغام بشه. در ادامه یه مقایسه بین این دوتا ابزار رو براتون میذارم:

1. اندازه و معماری

• Fluentd:

یک ابزار نسبتاً بزرگ‌تر و پیچیده‌تر است. این ابزار از Ruby و C نوشته شده و پلاگین‌های زیادی دارد که آن را به یک راه‌حل جامع برای جمع‌آوری و پردازش لاگ‌ها تبدیل می‌کند. Fluentd بیشتر برای محیط‌هایی با نیازهای پیشرفته و پیچیده مانند تجمیع داده‌های لاگ در مقیاس بالا استفاده می‌شود.

• Fluent Bit:

سبک‌تر و کم‌حجم‌تر است و به طور کامل به زبان C نوشته شده است. هدف اصلی آن ارائه یک راه‌حل کارآمد برای جمع‌آوری و ارسال لاگ‌ها با حداقل مصرف منابع است. Fluent Bit برای جمع‌آوری لاگ‌ها در دستگاه‌های IoT، edge و محیط‌های با منابع محدود ایده‌آل است.

2. مصرف منابع

• Fluentd:

به دلیل معماری پیچیده‌تر و قابلیت‌های گسترده، معمولاً حافظه و منابع CPU بیشتری نسبت به Fluent Bit مصرف می‌کند. این ابزار برای محیط‌هایی مناسب است که منابع کافی برای پردازش حجم زیادی از داده‌ها دارند.

• Fluent Bit:

به عنوان یک ابزار سبک، طراحی شده تا مصرف منابع بسیار کمی داشته باشد. بنابراین، برای محیط‌هایی که مصرف کم حافظه و CPU اولویت دارد، انتخاب بهتری است.

3. پلاگین‌ها و قابلیت‌ها

• Fluentd:

با داشتن یک اکوسیستم گسترده از پلاگین‌ها، Fluentd قادر است تقریباً هر نوع داده‌ای را پردازش کند و به هر مقصدی ارسال کند. این ویژگی آن را به یک ابزار بسیار منعطف برای سناریوهای پیچیده لاگ‌ تبدیل کرده است.

• Fluent Bit:

اگرچه Fluent Bit نیز از پلاگین‌های متنوعی پشتیبانی می‌کند، اما تعداد پلاگین‌ها و قابلیت‌های آن کمتر از Fluentd است. با این حال، پلاگین‌های اصلی برای جمع‌آوری و ارسال لاگ‌ها در آن وجود دارند و می‌تواند نیازهای اصلی را برآورده کند.

4. موارد استفاده

• Fluentd:

به دلیل قابلیت‌های پیشرفته و انعطاف‌پذیری بالا، برای تجمیع و پردازش لاگ‌ها در محیط‌های کلاسترهای بزرگ، سرورهای متعدد و سیستم‌های پیچیده مناسب است. از آن برای مدیریت لاگ‌ها در سیستم‌هایی مثل Kubernetes و محیط‌های ابری استفاده می‌شود.

• Fluent Bit:

بیشتر برای جمع‌آوری لاگ‌ها در edge devices، دستگاه‌های IoT و محیط‌هایی که نیاز به حداقل مصرف منابع دارند، استفاده می‌شود. همچنین به عنوان یک جمع‌آورنده لاگ در مقیاس کوچک‌تر یا به عنوان یک عامل جمع کردن لاگ در کنار Fluentd نیز به کار می‌رود.

5. پیچیدگی پیکربندی

• Fluentd:

با توجه به قابلیت‌های متعدد، پیکربندی Fluentd پیچیده‌تر است و نیاز به دانش بیشتری در مورد سیستم دارد. مدیریت و نگهداری این ابزار نیز به دلیل امکانات گسترده‌تر، ممکن است دشوارتر باشد.

• Fluent Bit:

پیکربندی ساده‌تری دارد و راه‌اندازی آن سریع‌تر و راحت‌تر است. این ویژگی باعث می‌شود برای کسانی که نیاز به راه‌حل‌های ساده و سریع دارند، مناسب باشد.

Sharding and Replication:

توی کلاستر اگه از یک دیتا تعداد بیشتری نگهداری کنم در واقع رپلیکا اونو بردیم بالاتر و اگه یک دیتایی که دارم رو به تعداد قسمت‌های کوچیک‌تر بشکنم در واقع شارد دیتا رو بردیم بالاتر. دو تا مفهوم خیلی مهم و حساس تو دیتابیس‌ها که برخی از آنها فقط Replication رو پشتیبانی می‌کنند. از شاردینگ میتونیم برای scale کردن کلاستر موقعی‌که تعداد ایندکس دیتا بالا میره کمک بگیریم و تعداد درست شارد اهمیت بالایی توی پرفورمنس ما داره. وقتیکه کوئری‌ها روی شاردهای مختلف ران بشن و به صورت موازی پاسخ برگرده، سرعت بالاتری رو نسبت به حالتیکه دیتا توی یک شارد هست تجربه میکنیم اما به شرطی که شاردهای مختلف‌مون توی نودهای مختلف باشن و تعداد کافی نود توی کلاسترمون داشته باشیم.

موقعیکه یک ایندکس ایجاد میشه میتونیم تعداد شارد و رپلیکا اون رو مشخص کنیم و بهترم هست همون موقع فقط این مقادیر رو ست کنیم چون تغییر مقدار شارد بعدا توی کلاستر باعث ایجاد مساله reindexing میشه که لود بالایی رو روی کلاستر میندازه و اصلا توصیه نمی‌شه. معمولا توصیه میشه هر شارد حجمی بین ۳۰ تا ۵۰ گیگ داشته باشه مثلا اگه دیتای شما ۳۰۰ گیگ هست شارد رو روی ۱۰ بذارید. انتخاب اینکه چند تا شارد و یا چند تا رپلیکا داشته باشیم خیلی مهمه و باید در ابتدای ایجاد ایندکس یه استیمیتی از میزان دیتای آن داشته باشیم.

با رپلیکیشن ما میتونیم دیتامون رو در برابر مشکلات احتمالی که ممکنه پیش بیاد محافظت کنیم البته به شرطی‌که نود کافی رو توی کلاسترمون داشته باشیم و هر رپلیکارو بذاریم روی یک نود. هر رپلیکایی که از یک شارد میگیریم باید توی نود متفاوتی ذخیره بشه تا زمانی‌که نود قبلی fail می‌کنه ما یک نسخه کپی از دیتا رو داشته باشیم. رپلیکاها به جز جلوگیری از downtime و محافظت از دیتا توی سرعت هم با ایجاد امکان پاسخ به صورت موازی به کوئری ها، کمک کننده هستن.

Backup and restore (Snapshot):

به نوعی اسنپ شات یک بک‌آپ از کلاستر توی اون لحظه هست. چندتا از استفاده های اسنپ شات و مواردی که که میتونه بهمون کمک کنه رو در ادامه براتون میارم.

• Regularly backup a cluster with no down time.

• Recover data after deletion or a hardware failure

• Transfer data between clusters

• Reduce your storage costs by using searchable snapshots in the cold and frozen data tiers.

Elasticsearch clustering:

وقتی ما تعدادی نود elasticsearch رو کنار هم قرار می‌دهیم می‌توانیم یک کلاستر مالتی نود الستیک سرچ ایجاد کنیم. کلاستری که به ما امکان این رو می‌ده که دیتاها رو ذخیره کنیم در کنار اینکه قدرت و سرعت خوبی برای سرچ و ایندکس به ما می‌دهد. ما با کلاسترینگ می‌تونیم High availability و Load Balancing به همراه Fault tolerance داشته باشیم مواردی که در استک‌های بزرگ به تمام آنها نیاز داریم و همواره باید طوری کار کنیم که SPOF نداشته باشیم.

برای ایجاد کلاسترینگ ما می‌توانیم نودهای خود را با نقش‌های (Role) مختلفی راه‌اندازی کنیم. نقش‌هایی که هر کدومشون برای ایجاد کلاسترینگ لازم است و نیاز است که یه نفر آن را برعهده بگیرد. برخی از نقش‌ها رو تو پست قبلی که در مورد نود تایپ‌ها صحبت کردیم بهش اشاره کردم. مثلا master یا data یا coordinator یا ingest node و … که هر کدومشون کاری رو تو کلاستر پیش می‌برند و انجام می‌دهند. نقش هر نود رو داخل کانفیگ آن می‌تونیم مشخص کنیم. موضوع دیگه‌ای که مهمه اینه که باید لیست نودهایی که داخل کلاستر هستند رو تو کانفیگ تمام نودهایی کلاستر قرار بدیم. این کار رو با کانفیگ discovery.seed_hosts انجام می‌دیم که به نوعی لیست تمام هاست‌های داخل کلاستر هست. موضوع بعدی مشخص کردن نودهایی است که برای bootstrap کردن کلاستر باید نقش ایفا کنند که کانفیگ cluster.initial_master_nodes برای این موضوع است. موارد متعدد دیگه‌ای برای کانفیگ کلاستر وجود داره ولی این چند تا نکته که گفتم از الزامات کلاسترینگ هست.

یکی از موارد مهمی که تو کلاسترینگ مطرحه اینه که داریم اون رو برای چه کاری و با چه هدفی ایجاد و کانفیگ می‌کنیم. این موضوع که باید در موردش تصمیم بگیریم در ایجاد و نوع پیاده‌سازی کلاستر ما خیلی مهمه و تاثیر گذاره. در ادامه به برخی از آن موارد اشاره می‌کنم:

کلاستر برای تیم توسعه و آزمایشی: تو این نوع پیاده‌سازی تنها فانکشنالیتی خود کلاستر اهمیت دارد و نه دیتا مهمه و نه پایدار بودن آن برای همین برای مدیریت راحت تر و صرفه‌جویی تو هزینه‌ها کلاستر رو به صورت یک نود راه‌اندازی می‌کنیم و ازش استفاده می‌کنیم. دقت کنید دیتایی که آنجا داره ذخیره می‌شه برامون مهم نیست و برای همین به تک نود اکتفا کردیم.

کلاستر برای پروداکشن: تو این موارد دیتا برای ما مهمه و خیلی اهمیت داره که کلاستر حتما همیشه در دسترس باشه برای همین باید به HA و LB و FT دقت کنیم و نوع پیاده‌سازی از سخت‌افزار مورد استفاده تا نحوه‌ی قرارگیری نودها در سرورها رو بررسی و بهترین جایگیری آنها رو داشته باشیم. چیزی که اینجا مهمه اینه که در زمان بروز خطا و خرابی کمترین آسیب به دیتا برسه و فانکشن اصلی سرویس ما قطع نشه.

ایجاد کلاستر برای استفاده خاص: در برخی از موارد نوع دیتا و مدل آن ساختار کلاستر رو عوض می‌کند مثلا اگر نیازه که دیتا به صورت مادام العمر نگهداری بشه می‌تونیم براش چرخه‌ی عمر داشته باشیم که بتوانیم از Hot و Warm و …. استفاده کنیم. پس با توجه به نوع استفاده کلاستر می‌تونیم دیزاین اون رو طراحی و بعد پیاده‌سازی کنیم.

OpenSearch:

اول یه کم تاریخچه‌ی الستیک رو با هم بررسی کنیم:

آقای Shay banon در سال ۲۰۰۴ نسخه اولیه‌ای از Elasticsearch به نام Compass را ایجاد کرد. برای ایجاد یک راه‌حل جستجوی مقیاس‌پذیر، توی نسخه سوم بخش‌های زیادی از Compass دوباره نوشته شد تا ساختاری که از پایه برای توزیع پذیری آماده شده شکل بگیره و از یک اینترفیس متداول یعنی Json over HTTP استفاده کرد که مناسب زبان‌های برنامه‌نویسی غیر از Java نیز باشد. اولین نسخه از Elasticsearch را در فوریه ۲۰۱۰ منتشر شد. شرکت Elastic NV در سال ۲۰۱۲ تأسیس شد تا خدمات و محصولات تجاری مرتبط با Elasticsearch و نرم‌افزارهای مربوطه را ارائه دهد. تا سال ۲۰۱۴ تونستن حدود صد میلیون دلار سرمایه جذب کردن، تنها ۱۸ ماه پس از تاسیس شرکت! در مارس ۲۰۱۵، شرکت Elasticsearch نام خود را به Elastic تغییر داد. در ژوئن ۲۰۱۸، Elastic برای عرضه اولیه عمومی با ارزیابی تخمینی بین ۱.۵ تا ۳ میلیارد دلار اقدام کرد. در ۵ اکتبر ۲۰۱۸، Elastic در بورس اوراق بهادار نیویورک فهرست شد. در ژانویه ۲۰۲۱، Elastic اعلام کرد که از نسخه 7.11 به بعد، کدهای تحت مجوز Apache 2.0 در Elasticsearch و Kibana را به دو مجوز Server Side Public License و Elastic License تغییر می‌دهد که هیچ‌یک از آن‌ها به عنوان مجوز متن‌باز شناخته نمی‌شود. Elastic این تغییر را به AWS نسبت داد و اعتراض کرد که AWS Elasticsearch و Kibana را به‌طور مستقیم به مصرف‌کنندگان ارائه می‌دهد و مدعی شد که AWS با Elastic همکاری نمی‌کند. نتیجه اش این شد که AWS و چنتا شرکت دیگه نیاز به اینکه Elastic به صورت متن باز توسعه بدن رو احساس کردن و فورک جدیدی از پروژه رو توی همون نسخه‌ها ایجاد کردن که بعدا اسمش رو هم گذاشتن OpenSearch. پس اپن‌سرچ جزو خانواده ابزار‌های سرچ هست که از سال ۲۰۲۱ فورک شده از پروژه‌های Elasticsearch و Kibana و توسط Amazon Web Services داره توسعه داده میشه.

و حالا آمازون اپن‌سرچ رو اینطوری معرفی میکنه:

اپن‌سرچ یک ابزار کامیونیتی محور و ۱۰۰ درصد اپن‌سورس تخت Apache 2.0-license هست که برای سرچ و آنالیز دسته بزرگی از یوزکیس‌ها مثل real-time application monitoring, log analytics, website search کارایی داره. کاملا اسکیل‌پذیر هست و میتونه دسترسی سریعی به دیتای حجیم از طریق داشبوردهاش و ابزارهای visualization بده که کار رو برای بررسی و آنالیز دیتا آسون میکنه و ازونجایی که از لایبرری‌های سرچ Apache Lucene استفاده می‌کنه می‌تونه قابلیت‌های زیادی مثل k-nearest neighbors (KNN) search, SQL, Anomaly Detection, Machine Learning Commons, Trace Analytics, full-text search رو فراهم کنه.

به صورت کلی تغییر لایسنسی که دادن و داستان‌هایی که ایجاد کردن باعث شد تا مسیر جدیدی ایجاد بشه و به صورت متن باز مسیر ادامه پیدا کنه. اخیرا شبیه همین داستان برای terraform هم اتفاق افتاد که تغییری تو نوع استفاده از کلادش انجام داد که خیلی‌ها شاکی شدن و مسیر جدیدی به نام OpenTofu رو ایجاد کردن و پروژه‌ی دیگه‌ای شکل گرفت و پیش رفت. به صورت کلی جامعه‌ی متن باز اگر موضوع براش خوشایند نباشه مسیر جدیدی رو ایجاد می‌کنند که در خیلی از موارد حتی از مسیر قبلی بهتر و پر شور تر هم پیش می‌ره.

خیلی از مواردی که تو Elastic Stack مورد نیاز است نیاز به لایسنس داره مثلا آلرتینگ کلا نیاز به لایسنس داره. فکر کن کل سامانه رو پیاده‌سازی کردی حالا که می‌خواد بهت آلرت بده مشکل لایسنس می‌خوری و نمی‌تونی ازش استفاده کنید. دیدم که تو ایران بیشتر این استک رو کرک می‌کنند و از تمام قابلیت‌های که داره استفاده می‌کنند. من زیاد فاز این کار رو ندارم. بیشتر دوست دارم که از ابزارهای متن‌باز استفاده کنم تا اینکه یه محصولی رو کرک کنم و ازش استفاده کنم.

Elastic Cloud:

یه موضوع دیگه‌ که خیلی برای ما داخل ایران شاید مسیر ولیدی نباشه استفاده از Cloud خود الستیک هست که امکانات زیاد رو روی کلاد خودش در اختیار ما قرار می‌ده و ما می‌تونیم به صورت کامل از تمام قابلیت‌هایی که در اختیارمون میذاره، استفاده کنیم. استفاده از کلاد الستیک به ما این امکان رو می‌ده که بدون اینکه درگیر پیاده‌سازی زیرساخت و خود ابزارها باشیم بتونیم از امکانات آنها نهایت استفاده رو کنیم. موضوع دیگه اینکه معمولا پیاده‌سازی و نگهداری این ابزارها نیاز به دانش زیادی داره و این دانش مستقل از دانش استفاده از خود ابزار هست. وقتی ما از کلاد استفاده می‌کنیم دیگه نیازی به دانش پیاده‌سازی و نگهداری اون ابزار مثلا elastic نداریم و تنها با دانش استفاده از اون ابزار می‌تونیم ازش بهره ببریم.

از مزایای استفاده از elastic cloud به موارد زیر می‌تونیم اشاره کنیم:

• استفاده‌ی آسان و ساده و بدون نیاز به دانش پیچیده

• ذخیره و صرفه‌جویی در زمان مخصوصا در ابتدای پروژه

• به راحتی می‌تونیم مقیاس‌پذیری داشته باشیم بدون دردسر

• امنیت بالاتر با توجه به کانفیگ توسط خود ارائه کننده محصول

• پشتیبانی و نگهداری فوق‌العاده با توجه به اینکه خود کمپانی داره ارائه می‌کنه

معمولا این مواردی که بهش اشاره می‌کنیم برای تمامی ابزارهایی که کلاد دارند مثلا Grafana و …. هم صادق است.

این میشه یه جمع بندی از استک الک امیدوارم در آینده فرصت بشه که برگردیم و با عمق بیشتر بررسی‌ش کنیم و کنار هم یاد بگیریم.

مراقب خودتون باشید. 🌹🐳🌹

خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.

🫀 Follow DockerMe 🫀

🔔 Follow YouTube 🔔

📣 Follow Instagram 📣

🖇 Follow LinkedIn DockerMe🖇

🔎 Follow Linkedin Ahmad Rafiee 🔎

🕊 Follow Twitter 🕊