https://virgool.io/feed/@m.shahsavanpour fa 2026-06-16 18:15:38 https://files.virgool.io/upload/users/6950/avatar/gWm2uP.jpg?height=120&width=120 https://virgool.io/@m.shahsavanpour https://tech.arvancloud.ir/کاهش-داون-تایم-down-time-روایت-دومین-سالگرد-استقرار-masakari-در-زیرساخت-ابری-ما-c3jpipikf5lq تصور کنید یک روز تابستانی است. شرکت ما در اوج ترافیک کاری به سر می‌برد. کاربران در حال استفاده از سرویس‌های پیاده‌سازی شده بر بستر ابرک‌های ما هستند: بعضی‌ها در حال رزرو هتل، برخی مشغول انجام تراکنش‌های مالی حساس، و گروهی دیگر سرگرم اجرای تحلیل‌های پیچیده داده. همه‌چیز ظاهراً عالی پیش می‌رود تا این که ناگهان یکی از میزبان‌ها (Host) در زیرساخت ابری ما از کار می‌افتد.همان‌طور که می‌توانید حدس بزنید، کابوسی ناگهانی همه را فرا می‌گیرد. کاربرانی که تا چند لحظه پیش با خیال راحت در سیستم مشغول فعالیت بودند، اکنون با خطاهای ناامیدکننده مواجه می‌شوند. آلرت ها(Alerts) به صدا در میان و نفر آنکال باید به سرعت فرآیند خالی کردن سرور از دسترس خارج شده رو شروع کنه.ما پیش‌تر هم از ابزارها و روش‌هایی برای افزایش دسترس‌پذیری (High Availability) استفاده کرده بودیم، اما واقعیت این بود که هنگام وقوع بحران، همچنان زمان ارزشمندی صرف ریکاوری سیستم و بازگرداندن ابرک‌ها می‌شد. همین لحظات حیاتی برای کاربران گران تمام می‌شد: تراکنش‌های حساس به تعویق می‌افتاد و در این میان برخی کاربران ناخشنود برای همیشه از ما روی برمی‌گردانند. از آن بدتر، اگر این مشکل در نیمه‌شب رخ می‌داد، تا بیدار شدن نفر آنکال، دسترسی به سیستم، و آغاز فرآیند ریکاوری، زمان بیشتری از دست می‌رفت.اینجا بود که نام "Masakari" وارد صحنه شد؛ ابزاری از اکوسیستم OpenStack که برای تضمین پایداری سرویس‌ها طراحی شده است. ما تصمیم گرفتیم فرصتی به Masakari بدهیم و ببینیم آیا واقعاً می‌تواند ما را از این وضعیت نجات دهد یا خیر.Automated VM Recovery with Masakari on Host Failureبعد از اجرای اولیه Masakari در محیط استیج (Staging) و بررسی نتایج، متوجه شدیم که برای رسیدن به عملکردی ایده‌آل، نیاز داریم آن را متناسب با شرایط زیرساخت خودمان سفارشی‌سازی کنیم. در واقع، Masakari به‌صورت پیش‌فرض قابلیت‌های فراوانی دارد، اما هر محیط ابری ویژگی‌ها، محدودیت‌ها و اولویت‌های خاص خود را دارد. همین موضوع باعث شد پس از اولین تست‌ها، به جای استقرار مستقیم در محیط عملیاتی، کمی دست نگه داریم و Masakari را با دقت بیشتری بررسی و بهینه کنیم.برای مثال، به دلیل برخی محدودیت ها، نیاز داشتیم که فرآیندهایی جهت اطمینان از داون بودن هاست اضافه کنیم. در بخش TaskFlow نیز لازم بود گام‌های ریکاوری را با جزئیات بیشتری بهینه کنیم تا مطمئن شویم در هنگام رخداد خرابی، دقیقاً همان مراحلی اجرا می‌شود که می‌خواهیم.آشنایی با Masakari: قهرمان لحظات بحرانی Masakari یک سرویس در OpenStack است که هدف اصلی‌اش حفظ پایداری ماشین‌های مجازی و جلوگیری از وقفه در سرویس‌های حیاتی می‌باشد. این ابزار به‌طور هوشمند رخدادهای خرابی را شناسایی می‌کند و بدون نیاز به مداخله نیروی انسانی، فرآیند ریکاوری و بازگرداندن سرویس‌ها را آغاز می‌نماید. در واقع، Masakari نقش یک ابرقهرمان پشت صحنه را بازی می‌کند و در لحظات بحران، با ورود سریع و خودکار، مانع از توقف چرخ کسب‌وکار دیجیتال ما می‌شود.زیرساخت پشتیبان: Corosync و Pacemaker Masakari برای انجام وظیفه به یک گروه پشتیبان قدرتمند نیاز دارد. Corosync و Pacemaker نقش ستون‌های زیرین این معماری را ایفا می‌کنند. Corosync پیام‌های heartbeat را بین هاست‌ها ردوبدل می‌کند تا وضعیت سلامت آنها مشخص باشد. Pacemaker نیز مانند یک مغز متفکر عمل می‌کند؛ وقتی هاستی پاسخی به heartbeat ندهد، Pacemaker متوجه می‌شود که مشکلی پیش آمده و آن هاست را موقتاً از چرخه خارج در نظر می‌گیرد. این اطلاعات سپس از طریق مکانیزم‌های متمرکز به Masakari تحویل داده می‌شود تا فرآیند ریکاوری آغاز گردد.HAClusterماژول‌های Masakari: از رصد تا تصمیم‌گیریmasakari-api: واسطی برای تعامل با کل سرویسmasakari-engine: مغز متفکر که تصمیم‌های اصلی برای ریکاوری را می‌گیرد و دستورات لازم را صادر می‌کند.masakari-hostmonitor: ناظر سلامت هاست‌ها که هرگونه اختلال را گزارش می‌کند.masakari-instancemonitor: پایشگر سلامت ماشین‌های مجازی.تقسیم‌بندی زیرساخت به سگمنت‌ها ما زیرساخت ابری خود را در ماساکاری به چندین سگمنت (Segment) تقسیم کردیم، هر سگمنت شامل مجموعه‌ای از هاست‌های مشابه (از نظر سخت‌افزار و نقش) بود. این سازماندهی باعث شد بتوانیم سیاست‌های ریکاوری مختلفی را برای هر سگمنت تعریف کنیم. بدین ترتیب اگر هاستی در یک سگمنت دچار مشکل می‌شد، Masakari با توجه به سیاست‌های همان سگمنت عمل می‌کرد.هاست‌های رزرو: ناجیان لحظات حساس تصور کنید در شهری که زندگی می‌کنید، همیشه یک ایستگاه آتش‌نشانی آماده عملیات وجود دارد. هاست‌های رزرو نیز چنین نقشی را برای ما ایفا می‌کنند. هر زمان یکی از هاست‌های اصلی دچار مشکل می‌شود، هاست رزرو وارد عمل می‌شود و بار ماشین‌های مجازی را به دوش می‌کشد.سیاست‌های ریکاوری و توسعه یک سیاست اختصاصی Masakari به‌صورت پیش‌فرض سیاست‌های مختلفی برای ریکاوری ارائه می‌کند، مانند:Reserved_host: مهاجرت ماشین‌ها به هاست‌های رزرو شده، با تضمین منابع کافی.Auto: مهاجرت خودکار ماشین‌ها به هر هاست در دسترس در همان سگمنت.Rh_priority: تلاش برای استفاده از reserved_host، و در صورت عدم موفقیت، بازگشت به Auto.Auto_priority: ابتدا تلاش برای Auto، و در صورت ناکامی، تلاش برای Reserved_host.ما در این میان یک سیاست جدید توسعه دادیم که ترکیبی از Auto و Reserved_host بود. تفاوت این سیاست با سایرین در این بود که قبل از شروع فرآیند ریکاوری، یک هاست رزرو را همیشه فعال و آماده نگه می‌داشتیم تا از وجود فضای کافی در کلاستر مطمئن باشیم. این رویکرد انعطاف‌پذیری Auto را با اطمینان خاطری که Reserved_host می‌دهد، ترکیب کرد.TaskFlow: مدیر سناریوهای ریکاوری یکی از جذاب‌ترین قابلیت‌های Masakari، استفاده از TaskFlow است. TaskFlow همچون یک کارگردان ماهر، صحنه‌پردازی عملیات ریکاوری را برعهده دارد. ما با استفاده از TaskFlow توانستیم گام به گام مشخص کنیم که در هنگام بروز خرابی، چه وظایفی انجام شود و ترتیب آنها چگونه باشد. این وظایف در سه مرحله تعریف شدند:Pre Tasks (پیش وظایف): این مرحله شامل اقداماتی است که قبل از آغاز ریکاوری اصلی انجام می‌شود:خط قرمز: بررسی تعداد نوتیفیکیشن های فعالابتدا کمی صبر می‌کنیم و وضعیت اعلان‌های اخیر را بررسی می‌کنیم. اگر تعداد اعلان‌های خرابی در مدت زمان مشخصی بیش از حد باشد، نشانه آن است که مشکل جدی است. در این صورت، جابه‌جایی‌ها متوقف شده و هاست در حالت تعمیر باقی می‌ماند تا از اقدامات غیرضروری جلوگیری شود. اگر این تسک پاس نشود، کلا فرآیند ریکاوری متوقف میشود.بررسی اینترفیس‌های شبکهدر این تسک وضعیت ارتباطات شبکه هاست از سورس‌های مختلف بررسی می‌شود. اگر شبکه پایدار باشد، ریکاوری متوقف و هاست از حالت `در انتظار تعمیر` خارج می‌شود، زیرا ظاهراً مسئله حل شده است. اما اگر هیچ کدام از اینترفیس های هاست پاسخگو نباشند و این اختلال در چندین منبع مختلف تأیید شود، مسیر ریکاوری ادامه می‌یابد.غیرفعال کردن هاست در کلاستربرای جلوگیری از استقرار ماشین‌های مجازی جدید روی هاست مشکل‌دار، سرویس Nova آن هاست غیرفعال می‌شود. این کار از بدتر شدن شرایط جلوگیری می‌کند.هدف از Pre Tasks این است که مطمئن شویم هر اقدام بعدی درست و به‌جا است و بی‌مورد سراغ جابه‌جایی یا تغییر زیرساخت نرویم.Main Tasks (وظایف اصلی): این مرحله قلب عملیات ریکاوری است و شامل اقداماتی است که برای بازگرداندن سرویس به حالت پایدار انجام می‌شوند. برای مثال:آماده‌سازی ماشین‌های مجازی:ماشین‌های مجازی که نیاز به جابه‌جایی، توقف یا قرارگیری در حالت خاصی دارند، پیش از آغاز عملیات مشخص می‌شوند. این کار کمک می‌کند در طول ریکاوری، دقیقاً بدانیم با هر ماشین چه باید کرد.اطلاع‌رسانی به کاربران:برای آن‌که کاربران از شرایط باخبر باشند، به آنهایی که پیش از خرابی، سرویس فعال داشتند، پیام اطلاع‌رسانی ارسال می‌شود. این کار اعتماد و آگاهی کاربران را حفظ می‌کند.فعال کردن هاست رزرو:برای اطمینان از وجود منابع کافی در هنگام جابه‌جایی، یک هاست رزرو نیز در کلاستر فعال می‌شود. این هاست در واقع مثل نیروی کمکی عمل می‌کند تا در صورت کمبود منابع، ماشین‌های مجازی بتوانند به آن منتقل شوند.جابه‌جایی ماشین‌های مجازی:در این تسک ماشین‌های مجازی از هاست معیوب به سایر هاست‌ها منتقل می‌شوند. اگر ماشینی در حالت نامناسبی باشد، ابتدا مشکلات آن برطرف شده و سپس جابه‌جا می‌شود. اگر حین جابه‌جایی خطایی رخ دهد، ماشین‌های مشکل‌دار شناسایی و تلاش مجدد انجام می‌شود. در پایان، اگر ماشینی روی هاست معیوب باقی مانده باشد، فهرست آنها ثبت می‌شود تا در مراحل بعدی رسیدگی شوند.در این بخش، TaskFlow مراحل را به‌صورت ترتیبی و با در نظر گرفتن وابستگی‌ها اجرا می‌کند.Post Tasks (وظایف پس از ریکاوری):وقتی جابه‌جایی‌ها کامل شد و سرویس‌ها به ثبات رسیدند، نوبت به اقدامات نهایی می‌رسد.بازگرداندن هاست رزرو به حالت اولیه:هاست رزروی که فعال شده بود، دوباره غیرفعال و برای استفاده در سناریوهای بعدی آماده می‌شود.در انتهای این فرآیند، هاست معیوب در حالت تعمیر باقی می‌ماند تا نیروی فنی مشکل اصلی آن را برطرف کرده و هاست را مجدداً به چرخه عملیاتی بازگرداند. با این رویکرد چندلایه، Masakari کمک می‌کند تا فرآیند ریکاوری هوشمند، مرحله‌به‌مرحله و با کمترین تأثیر منفی بر کاربران و زیرساخت انجام شود.یکی دیگر از چالش‌های جالبی که هنگام استفاده از سرویس Masakari در کلاستر با آن مواجه شدیم، حفظ وضعیت (State) ماشین‌های مجازی قبل از ریبوت یک هاست بود. چرا؟ چون به محض اینکه هاست ریبوت می‌شد و سرویس nova-compute دوباره بالا می‌آمد، همه ماشین‌های مجازی به حالت خاموش (ShutOff) تغییر وضعیت می‌دادند. بدتر از آن؟ دیگر نمی‌شد از اکشن Evacuate استفاده کرد، بنابراین اگر عملیات ریکاوری یک هاست در میانه راه بود، از لحظه بوت شدن هاست مشکل دار، دیگر هیچ ابرکی امکان جابه جایی نداشت.برای رفع این چالش، راه‌حل خلاقانه‌ای پیاده‌سازی کردیم: یک systemd service unit ساده اما هوشمند که روی Compute Nodes مستقر می‌شود، پیاده سازی کردیم. وظیفه اصلی این سرویس چیست؟ اگر یکی از هاست‌ها ریبوت شود، سرویس به‌صورت خودکار nova-compute را در حالت Down نگه می‌دارد تا بتوانیم بدون دردسر وضعیت ماشین‌های مجازی را مدیریت کنیم.این سرویس مثل یک نگهبان عمل می‌کند که می‌گوید: "نه! تا وقتی که مطمئن نشدم همه چیز سر جای خودش است، nova-compute نمی‌تواند وارد عمل شود." با این کار، نه‌تنها از تغییر وضعیت ماشین‌ها جلوگیری کردیم، بلکه امکان استفاده از اکشن Evacuate را نیز حفظ کردیم. یک راه‌حل ساده، اما موثر برای یک مشکل اساسی!نتیجه: کاهش چشمگیر داون‌تایم پس از استقرار Masakari، تنظیم سیاست‌های جدید، و توسعه هوشمندانه TaskFlow، داون‌تایم کاربر به طرز چشمگیری کاهش یافت. در بسیاری از سناریوها، به جای چندین ساعت، تنها در حد چند دقیقه اختلال داشتیم. به طور میانگین، با استفاده از سیاست‌های جدید و معماری TaskFlow، ما توانستیم داون‌تایم را درصد زیادی نسبت به قبل کاهش دهیم؛ همچنین لود کاری و استرس رو برای نفر آنکال تیم کاهش دادیم. کاری که برای ما، در دومین سالگرد استقرار Masakari، یک موفقیت بی‌نظیر بود.پایان خوش داستان Masakari برای ما همان قهرمانی بود که بی‌سروصدا پشت صحنه کار میکنه. هر زمان هاستی دچار مشکل میشه، Masakari وارد عمل میشه: هاست رزرو فعال میشه، ماشین‌های مجازی بی‌درنگ منتقل میشوند، کاربران مطلع میشوند، و در نهایت، سرویس‌ها در کوتاه‌ترین زمان ممکن به روال عادی برمیگردند و ما با خاطری آسوده‌تر به ادامه کار میپردازیم.این تجربه نشان داد که با ابزارهای مناسب، برنامه‌ریزی هوشمندانه، و مکانیزم‌های خودکارسازی مانند Masakari و TaskFlow، می‌توان داون‌تایم را به حداقل رساند و اعتماد را به فضای ابری بازگرداند. در دنیایی که هر ثانیه اهمیت دارد، این سرمایه‌گذاری برای ما ارزشمند بود و دومین سالگرد استقرار Masakari گواهی است بر موفقیت این رویکرد. Mina Shahsavan Mina Shahsavan Tue, 24 Dec 2024 10:08:20 +0330 https://virgool.io/@m.shahsavanpour/%D9%86%D9%82%D8%B4%D9%87-%D8%B1%D8%A7%D9%87-%D8%AC%D8%A7%D9%85%D8%B9-%D8%A7%D8%B3%D8%AA%D9%82%D8%B1%D8%A7%D8%B1-%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D8%A7%D8%B2-%D8%A7%DB%8C%D8%AF%D9%87-%D8%AA%D8%A7-%D9%BE%D8%B1%D9%88%D8%AF%D8%A7%DA%A9%D8%B4%D9%86-fjpbullcpeli استقرار سرویس جدید یا ارتقای یک سرویس موجود همواره چالش‌هایی را به همراه دارد که برای پیاده‌سازی موفقیت‌آمیز آنها، نیازمند رویکردهای سازمان‌یافته و مراحل مشخصی هستیم. این راهنما به عنوان یک نقشه راه نسبتا جامع برای این فرآیند عمل می‌کند و با تاکید بر ساده‌سازی فرآیند، کاهش خطرات و تقویت همکاری تیم، گام‌های اساسی برای اطمینان از استقرار موفقیت‌آمیز را تشریح می‌کند. این راهنما همچنین به ریویو کننده این امکان را می‌دهد که در هر مرحله به انتظارات و نیازهای خود برای تحویل یا بررسی موارد مختلف پروژه دقت کند. از تحلیل نیازها و طراحی معماری تا پیاده‌سازی، آزمایش و نظارت، این راهنما به عنوان یک راهنمای جامع بر پایه تجربه تیمی ما ارائه شده است.توجه داشته باشید:برخی از مراحل به عنوان یک الزام در نظر گرفته می‌شوند و باید به دقت برای هر استقرار پیروی شوند.برخی از مراحل اختیاری هستند و ضرورت آن‌ها ممکن است بر اساس طبیعت سرویس و الزامات پروژه خاص متفاوت باشد.مرحله ۱: تحلیل نیازها (چه چیزی لازم داریم)قبل از ورود به جزئیات سرویس خود، کمی وقت بگذارید تا بفهمید چه چیزی لازم است. نقاط لازم و مورد نظر را جمع‌آوری، بررسی و به صورت مستند ثبت کنید. این شامل ویژگی‌ها، کارایی، قابلیت اطمینان، امنیت و قابلیت مقیاس‌پذیری است. این مرحله به شما کمک می‌کند مرزها و اهداف سرویس خود را تعیین کنید.جمع‌آوری تمام نیازهای تجاری، سیستمی و انسانیاعتبارسنجی نیازها از طریق مشاوره با ذی‌نفعانثبت نیازها و جزئیات در یک سند نیازمندی‌هاتعریف دامنه، اهداف و محدودیت‌های سرویسخروجی مرحله:ایجاد تسک مرتبطایجاد سند نیازمندی‌هامرحله ۲: طراحی معماری (نقشه را نقاشی کنید)وقتی که با نیازها آشنا شدید، وقت آن است که طرح‌ها را تهیه کنید. طراحی تصویر کلی سرویس خود را انجام دهید و تصمیم بگیرید که چگونه به کامپوننت‌ها یا لایه‌های مختلف تقسیم شود و چگونه همۀ آن‌ها با هم ترکیب شوند. در نظر داشته باشید که چگونه پیاده سازی را ماژولار نگه دارید، در جایی که لازم است، انتزاع انجام دهید و اطمینان حاصل کنید که راحت و قابل فهم است. این مرحله اطمینان می‌دهد که سرویس شما با کیفیت بالا، سازگار و قابل انجام است.خروجی مرحله:انجام تحقیق اولیهایجاد طراحی سطح بالا (HLD)توسعۀ یک سند فنی جهت اطمینان از نظر امکان‌پذیری، کیفیت و سازگاریمرحله ۳: تحقیق و توسعه (شیرجه بزنید در دل تحقیق و توسعه)حالا وقت آن رسیده که دست‌هایتان را کثیف کنید. به تحقیق و توسعه مشغول شوید تا ایده‌های خود را به واقعیت تبدیل کنید. راه‌حل‌های نوآورانه را بررسی کنید، با رویکردهای مختلف آزمایش کنید و از این موضوع که سرویس شما بهترین حالت ممکن را دارد و از به‌روزترین تکنولوژی‌های موجود استفاده می‌کنید، اطمینان حاصل کنید.دربارۀ فناوری‌ها و راه‌حل‌ها تحقیق کامل انجام دهید.رویکردهای نوآورانه و راه حل‌های بالقوه را بررسی کنید.بر اساس نتایج تحقیق، مسیر روشنی را برای توسعه شناسایی کنید.هر مشکل امنیتی که ممکن است با آن مواجه شویم را ارزیابی و شناسایی کنید.خروجی مرحله:1- آماده‌سازی تمامی اسناد فنیبهترین متدها و تکنیک‌ها (Best Practices)چه فناوری‌هایی را می‌خواهیم استفاده کنیمتمام اطلاعات دربارۀ سرویس2- مشخص کردن زمان تحویل (با احتمال اینکه ممکن است در طول فرایند استقرار تغییر کند)3- ایجاد طراحی سطح پایین (LLD)مرحله ۴: پیاده‌سازی سرویس (سرویس را زنده کنید)بخش جذاب! تمام برنامه‌ریزی‌هایتان را در دست بگیرید و آن‌ها را به واقعیت تبدیل کنید. کد بنویسید، بسازید و اطمینان حاصل کنید که سرویس شما آماده برای درخشش است. با اندیشیدن خلاقانه اجازه دهید ویژگی‌های مدنظرتان به واقعیت تبدیل شوند.پیاده‌سازی سرویس مطابق با مشخصات طراحیانجام بررسی دقیق کد برای اطمینان از کیفیت و رعایت بهترین روش‌هاخروجی مرحله:مخزن گیت سرویسبررسی کددریافت بازخورد از همپای کارمرحله ۵: آزمایش سرویس (یک آزمایش در محیط تستی)قبل از نمایش بزرگ، بیایید تمرین کنیم. سرویس خود را در یک محیط تستی ایمن آزمایش کنید. این اطمینان حاصل می‌شود که همه چیز قبل از استقرار در پروداکشن به طور صحیح کار می‌کند و از هرگونه مشکل غیر منتظره در محیط پروداکشن پیشگیری شود.خروجی مرحله:آزمایش سرویس در محیط استیجشناسایی و رفع هر مشکل یا باگانجام آزمایش‌های عملکرد، امنیت و قابلیت اعتمادمرحله ۶: اتومیشن (تنظیم به حالت خودکار)وقتشه که زندگی رو آسون‌تر کنیم. وظایف تکراری را به صورت اتوماتیک درآورید تا امور به سرعت پیش برود. این مرحله هم درباره کارآمدی است. اجازه دهید سرویس شما با حداقل دخالت دستی کارهای خود را انجام دهد.خروجی مرحله:پیاده‌سازی اتومیشن برای وظایف تکراری (مانند IaC, GeiOps, CI/CD)پیاده سازی مکانیزم‌های پست‌چک و پری‌چک جهت ولیدیت سرویسمرحله ۷: نظارت و هشداردهی (چشمت روش باشه)هوشمند باشید! سیستم‌های قوی نظارت و هشداردهی را پیاده‌سازی کنید تا به دقت به سرویس خود نظارت داشته باشید. مشکلات را قبل از آنکه به مشکلات تبدیل شوند، شناسایی کنید و همه چیز را مانند یک ماشین روغن‌کاری شده به راه بیندازید.خروجی مرحله:پیاده‌سازی متریک‌های مانیتورینگ و داشبوردهای گرافاناافزودن هشدارهای وارنینگ یا کریتیکالایجاد فرمت مناسب برای لاگ و پیاده‌سازی مکانیزم ارسال لاگ به CLMپیاده‌سازی Tracing ( با توجه به سرویس این مرحله اختیاری است)مرحله ۸: راه‌حل پشتیبان‌گیری (برای بدترین حالت برنامه‌ریزی کنید)امید به بهترین‌ها را داشته باشید، اما برای بدترین حالت برنامه‌ریزی کنید. یک راه‌حل پشتیبان‌گیری قوی راه‌اندازی کنید تا اطمینان حاصل کنید که می‌توانید به زیبایی از هر بحران ناگهانی نجات پیدا کنید. سیستم پشتیبان را به صورت منظم تست کنید تا اطمینان حاصل شود که آمادگی بازیابی داده‌ها وجود دارد.خروجی مرحله:پیاده‌سازی یک راه‌حل جامع برای پشتیبان‌گیری و بازیابیمرحله ۹: مهندسی آشوب (از هرج و مرج استقبال کنید)برای هرگونه رخداد غیرمنتظره آماده شوید. به طور عمد کمی هرج و مرج را در سرویس‌تان تزریق کنید تا ببینید چقدر خوب سرویس در شرایط غیر قابل پیش‌بینی عمل می‌کند. با سوپرایز کردن سرویس، مطمئن شوید که سرویس پایدار و قابل اطمینان باقی می ماند.اطمینان حاصل کنید که این سرویس در برابر سناریوهای غیرقابل پیش‌بینی انعطاف پذیر است.خروجی مرحله:ایجاد مستندات برای سناریوهای بحران و اجرای اقدامات لازممرحله ۱۰: آگاه‌سازی تیم (همکاری تیمی)همراه هم رشد کنید! محیط همکاری را تقویت کنید و اطمینان حاصل کنید که همۀ اعضای تیم - هم جدید و هم قدیمی - دانش و حمایت لازم برای روال پشتیبانی، کانتریبیوت و استقرار سرویس را دارند. این مرحله درباره ساختن و حفظ یک تیم قوی است که به صورت بی‌درنگ می‌تواند سرویس پیاده‌سازی شده را پشتیبانی کند.فرایندهای آنبوردینگ برای همۀ اعضای جدید و قدیمی تیم را تعیین کنید.خروجی مرحله:برگزاری جلسۀ اشتراک دانش برای همۀ اعضای تیماضافه کردن موارد لازم به مستندات آنبوردینگمرحله ۱۱: ادغام با ابزارها و سرویس‌های دیگر (اتصال نقاط)سرویس شما در انزوا زندگی نمی‌کند. آن را یکپارچه با سایر ابزارها و سرویس‌های موجود در اکوسیستم خود کنید. اگر سرویس شما نیازمندی‌هایی دارد که لازم است در IaC دیده شود، یا تغییری ایجاد شود، در این مرحله یکپارچه‌سازی را انجام دهید.دستیابی به یکپارچگی با سایر ابزارها و سرویس‌هاخروجی مرحله:ادغام سرویس جدید با IaC ( تغییر یا افزودن پلی بوک ها یا سرویس های متناظر جهت یکپارچگی با سرویس جدید)مرحله ۱۲: استقرار (راه‌اندازی در Production)لحظه بزرگ! سرویس خود را در محیط پروداکشن مستقر کنید. اینجاست که تمامی تلاش‌های شما به ثمر می‌نشیند و سرویس شما آماده برای نمایش اصلی است.خروجی مرحله:انجام چک‌لیست پس از استقرار جهت اطمینان از اجرای صحیح سرویسمرحله ۱۳: بهبود مداوم (همیشه بهتر شوید)این پایان نیست؛ این یک شروع جدید است. به طور مداوم به دنبال راه‌های بهبود و تقویت سرویس خود بگردید. بهبود مستمر را ملکۀ ذهن کنید تا سرویس را همیشه درجه یک نگه دارید.خروجی مرحله:دریافت بازخورد و برگزاری بازبینی‌های منظم برای بهبود‌های عملیاتی Mina Shahsavan Mina Shahsavan Sat, 30 Mar 2024 17:58:19 +0330 https://tech.arvancloud.ir/distributed-tracing-and-jaeger-aqrzzmvomfaz امروزه استفاده از معماری Microservice انتخاب بدیهی دولوپرها شده است. در معماری Microservice یک برنامه monolithic به گروهی از سرویس های دپلوی شده شکسته می شود.زمانی که ما تعداد زیادی از این میکروسرویس های در هم تنیده و مرتبط با هم داشته باشیم، تقریبا رسم شمای کلی وابستگی ها و درک مستقیم نحوه اجرای یک درخواست غیر ممکن یا خیلی سخت و زمان بر می شود.در صورت بروز خطا در یک برنامه monolithic ، درک مسیر درخواست و تجزیه و تحلیل علت اصلی خطا بسیار آسان تر است. اما در معماری microservice ،لاگ برنامه به تنهایی قادر به ارائه تصویر کامل مشکل نیست.اوپن تریسینگ (Opentracing) یک استاندارد مانیتورینگ برای oss package ها یا اپلیکیشن ها می باشد که دولوپرها می توانند از آن برای مانیتورینگ میکروسرویس ها استفاده کنند.مانیتورینگ و لاگ جایگاه بسیار ویژه ای در سیستم دارند اما هیچ کدام نمی توانند جای سیستم opentracing را بگیرند چرا که از زمان شروع یک درخواست تا دریافت یک پاسخ، یک مسیر بسیار پیچیده در سیستم وجود دارد که فقط یک سیستم distributed میتواند مانیتورینگ کل آن را انجام دهد.سیستم opentracing یک سیستم جدید نیست و بیش از یک دهه است که گوگل از آن استفاده میکند و پروژه هایی مانند Dapper و Zipkin را برای خود دولوپ کرده است. در توصیف Opentracing از واژه instrumentation استفاده میشود چرا که همانند یک رهبر ارکستر یک هارمونی بین تمام میکروسرویس ها ایجاد می کند، بدین صورت که اگر از لحظه ارسال ریکوئست تا دریافت ریسپانس را یک مسیر در نظر بگیریم با استفاده از یک یونیک آیدی که در ابتدا ایجاد میشود میتوان تمام مراحل طی شده در سیستم را بررسی کرد و از این طریق latency پکت ها در سیستم و شمای کلی ارتباط بین میکرو سرویس ها را متوجه شویم.برای جلوگیری از شکست این instrumentation به یک مکانیزم استاندارد و واحد نیاز داریم که در تمام مراحل causal chain را حفظ کند و رفتار سیستم را توصیف کند.اوپن تریسینگ موارد زیر را استاندارد سازی می کند :1- Standardized span management2- Standardized inter-process propagation3- Standardized active span management4- Standardized in-band context encoding5- Standardized out-of-band trace data encیگر (Jaeger) با الهام از Dapper و OpenZipkin یک سیستم تریسینگ توزیع شده است که توسط اوبر پیاده سازی شده و برای مانیتورینگ و ترابلشوتینگ میکروسرویس ها استفاده می شود:Distributed context propagationDistributed transaction monitoringRoot cause analysisService dependency analysisPerformance / latency optimizationاجزای اصلی JaegerSpan‌ یک واحد منطقی از کار در Jaeger را نشان می دهد که دارای نام عملیات ، زمان شروع عملیات و مدت زمان آن است. Span ها ممکن است تو در تو قرار گرفته و برای مدل سازی روابط پیاده سازی شوند.Traceیک مسیر اجرایی یا دیتای سیستم است و میتوان به عنوان یک گراف چرخه ای از span ها در نظر گرفت.Jaeger Client Librariesپیاده سازی اختصاصی api های opentracing در زبان های برنامه نویسی است. یک instrumented service زمانی که یک ریکوئست دریافت کند یک span را ایجاد میکند و اطلاعات context که شامل trace id , span id و baggage است را به آن اتچ می کند. Baggage یک سری متادیتای اضافه است که دولوپر میتواند به span اضافه نماید.Agentیک دیمن شبکه ای است که span های ارسالی بر بستر udp را دریافت کرده و به صورت دسته ای به collector ارسال میکند. Agent به صورتی طراحی شده که به عنوان یک مولفه زیرساخت بر روی تمام هاست ها مستقر شود. Agent پیچیدگی روتینگ و دیسکاوری collector ها را از کلاینت مخفی می کند.Collectorکالکتور تریس های ارسالی از agent را دریافت و آن ها را از طریق یک سری پایپ لاین های پردازشی اجرا می کند. در حال حاضر پایپ لاین ها تریس ها را ولیدیت، ایندکس گذاری و تغییرات لازم را اعمال میکنند و در نهایت آن ها را ذخیره می کنند. استوریج Jaeger یک پلاگین قابل اتصال است که در حال حاضر از Cassandra, Elasticsearch و Kafka پشتیبانی می کند.Queryسرویس دریافت تریس ها از استوریج و نمایش آن ها در UI می باشد.Ingesterسرویس جهت خواندن تاپیک های کافکا و نوشتن در سایر استوریج ها می باشد.جهت پیاده سازی Jaeger از لینک زیر استفاده نمایید : https://www.jaegertracing.io/docs/1.26/deployment/ Useful Links : https://www.jaegertracing.io/docs/ https://medium.com/opentracing/take-opentracing-for-a-hotrod-ride-f6e3141f7941 https://medium.com/velotio-perspectives/a-comprehensive-tutorial-to-implementing-opentracing-with-jaeger-a01752e1a8ce https://github.com/jaegertracing/jaeger Mina Shahsavan Mina Shahsavan Sat, 02 Oct 2021 13:19:26 +0330