تصویر کلی
Sentinel نمونه‌های Redis را پایش می‌کند و درباره Subjectively Down و Objectively Down با چند Sentinel به توافق می‌رسد.
برای فهم این موضوع بهتر است اجزا را به‌عنوان یک مسیر ببینیم، نه مجموعه‌ای از گزینه‌های مستقل. در Production معمولاً مشکل زمانی شکل می‌گیرد که تنظیم روی دیسک، وضعیت Runtime و فرض تیم درباره رفتار سیستم با هم یکی نیستند. به همین دلیل مشاهده وضعیت مؤثر، Log و Metric باید کنار Configuration بررسی شود.
اجزای اصلی و مرز مسئولیت
Quorum برای اعلام ODOWN مهم است؛ انجام Failover علاوه بر آن به اکثریت قابل دسترس Sentinelها نیاز دارد.
در طراحی عملی، برای هر جزء یک سؤال روشن بنویسید: چه ورودی می‌گیرد، چه خروجی تولید می‌کند، چه Stateای نگه می‌دارد و در خرابی چه کسی مسئول Recovery است. این مدل ساده کمک می‌کند خطاهای شبکه، هویت، ذخیره‌سازی یا Replication به‌اشتباه به جزء دیگری نسبت داده نشوند.
خطاهای رایج
کلاینت‌ها باید راه کشف Primary جدید را داشته باشند و Split Brain، latency شبکه و persistence قبل از Production آزموده شوند.
خطای دیگر، فعال‌کردن قابلیت پیشرفته بدون تعریف معیار موفقیت است. قبل از تغییر، Baseline بگیرید؛ بعد از تغییر همان Signalها را مقایسه کنید. اگر سیستم توزیع‌شده است، Failure Modeهای قطع شبکه، Restart، Lag، Timeout و از دست‌رفتن Dependency را نیز آزمایش کنید.
چک‌لیست عملی
- نسخه و Configuration مؤثر را ثبت کنید، نه فقط فایل مورد انتظار را.
- مسیر داده و کنترل را جدا رسم کنید.
- Health، Latency، Error Rate و ظرفیت را قبل و بعد از تغییر مقایسه کنید.
- برای تغییرات Stateful، Backup/Restore یا Rollback واقعی را آزمایش کنید.
- دسترسی مدیریتی را حداقل کنید و Log تصمیم‌ها را نگه دارید.
- مستندات همان نسخه محصول را مرجع نهایی قرار دهید.
تمرین IROSG
یک محیط کوچک آزمایشی بسازید و فقط یک Failure را تزریق کنید؛ مثلاً قطع Upstream، حذف یک Replica، خطای DNS یا تغییر Route. قبل از آزمایش بنویسید انتظار دارید کدام Metric و Log تغییر کند. بعد نتیجه واقعی را با انتظار مقایسه کنید. این تمرین معمولاً سریع‌تر از حفظ‌کردن Optionها، مدل ذهنی سیستم را اصلاح می‌کند.
مرجع
این راهنما بر پایه مستندات رسمی Redis نوشته شده و مثال‌های عملی تحریریه برای آموزش دفاعی و عملیاتی هستند.
سه تصمیم جدا در فرایند failover
Sentinel سلامت Redis را مشاهده می‌کند، درباره خرابی با دیگر Sentinelها تبادل نظر می‌کند و در شرایط لازم فرایند جابه‌جایی نقش را هماهنگ می‌سازد. تشخیص یک ناظر از قطع بودن master با توافق لازم برای اعلام خرابی و مجوز انجام failover یکسان نیست. همین تفاوت توضیح می‌دهد چرا پایین آوردن quorum به تنهایی تضمین نمی‌کند در هر جدایی شبکه failover رخ دهد. طراحی باید هم تشخیص خرابی و هم دسترسی به اکثریت لازم برای انتخاب هماهنگ‌کننده را در نظر بگیرد.
فرض کنید سه Sentinel در سه محل مستقل دارید و quorum دو است. یک Sentinel که به master دسترسی ندارد، هنوز نمی‌تواند صرف مشاهده شخصی خود خرابی سراسری را نتیجه بگیرد. اگر دو ناظر به نتیجه لازم برسند، مرحله بعدی همچنان به قواعد انتخاب رهبر وابسته است. حال اگر شبکه به بخش‌هایی تقسیم شود، سمتی که اکثریت مناسب را ندارد نباید آزادانه نقش‌ها را عوض کند. این رفتار برای جلوگیری از تصمیم‌های متعارض اهمیت دارد، هرچند از دید کاربر ممکن است شبیه تأخیر در بازیابی باشد.
تعداد فرایند با استقلال خرابی فرق دارد
اجرای سه Sentinel روی یک ماشین، تحمل از دست رفتن آن ماشین را ایجاد نمی‌کند. حتی اجرای آن‌ها روی سه ماشین که همگی یک برق یا مسیر شبکه مشترک دارند، همه خطرها را جدا نکرده است. جای‌گذاری باید با دامنه خرابی مورد انتظار هماهنگ باشد. لازم نیست هر جزء همیشه در دورترین نقطه ممکن باشد؛ تأخیر و قابلیت ارتباط نیز اهمیت دارند. هدف این است که یک خرابی واحد، هم master و هم تمام ناظران لازم برای تصمیم را از دسترس خارج نکند.
Sentinel را با Redis Cluster اشتباه نگیرید. در این الگو، هدف اصلی دسترس‌پذیری مجموعه master و replica است و توزیع خودکار کلیدها میان shardهای متعدد موضوع دیگری است. اگر مشکل شما ظرفیت یک master است، افزودن Sentinel ظرفیت نوشتن را تقسیم نمی‌کند. این تمایز در انتخاب معماری مهم است؛ ابزار failover را نباید راه‌حل همه نیازهای مقیاس‌پذیری معرفی کرد. نیاز خواندن، نوشتن و اندازه داده را جدا تعریف کنید.
replication ناهمگام و احتمال از دست رفتن داده
Redis در الگوی رایج replication ناهمگام دارد. ممکن است master پاسخی به مشتری داده باشد ولی آخرین نوشتن هنوز به replica منتخب نرسیده باشد. اگر همان لحظه master از دست برود، failover می‌تواند نسخه‌ای را بالا بیاورد که آن تغییر را ندارد. Sentinel این فاصله را به طور جادویی حذف نمی‌کند. برای داده‌ای که از دست رفتن حتی یک نوشتن پذیرفتنی نیست، نیاز سازگاری را صریح تحلیل کنید و صرف وجود replica را تضمین تراکنشی کامل ندانید.
تنظیمات مربوط به حداقل replica و تأخیر قابل قبول می‌توانند رفتار پذیرش نوشتن را محدود کنند، اما هزینه دسترس‌پذیری و محدودیت خود را دارند. درخواست تأیید replication نیز باید با معنای واقعی آن در نسخه و سناریو بررسی شود. هیچ گزینه‌ای را بدون آزمون به عنوان تضمین مطلق دوام معرفی نکنید. در آزمایش، شمارنده یا مجموعه‌ای از شناسه‌های ترتیبی بنویسید و پس از failover آنچه باقی مانده را با پاسخ‌های تأییدشده مشتری مقایسه کنید. این روش فاصله واقعی را آشکار می‌کند.
مشتری باید مقصد تازه را کشف کند
موفقیت انتخاب master تازه پایان کار نیست. کتابخانه مشتری باید Sentinel را پشتیبانی کند یا سازوکار مطمئن دیگری برای یافتن مقصد داشته باشد. برنامه‌ای که یک IP ثابت را برای همیشه در connection pool نگه می‌دارد، ممکن است همچنان به نقش قبلی وصل شود. نام منطقی master در تنظیم مشتری باید با نام پایش‌شده یکسان باشد. دسترسی مشتری به Sentinel و دسترسی به خود Redis نیز دو مسیر جدا هستند و هر دو نیاز به آزمون دارند.
هنگام جابه‌جایی، بعضی عملیات ممکن است خطا یا timeout بگیرند. retry کورکورانه می‌تواند عملیاتی را دوبار اجرا کند؛ به‌خصوص وقتی پاسخ گم شده ولی نوشتن انجام شده است. برنامه باید برای عملیات حساس شناسه درخواست یا منطق تکرارپذیر مناسب داشته باشد. بازیابی اتصال و بازیابی معنای عملیات یک موضوع نیستند. در آزمون، علاوه بر مدت قطع، تعداد پاسخ نامعلوم و رفتار تکرار درخواست را ثبت کنید تا اثر واقعی بر کاربر روشن شود.
انتخاب replica و بازپیکربندی
همه replicaها لزوماً گزینه یکسانی برای ارتقا نیستند. میزان عقب‌ماندگی، اولویت و وضعیت اتصال در انتخاب اثر دارند. replica دوردست یا کم‌توانی که فقط برای گزارش نگهداری شده ممکن است گزینه مناسبی برای بار اصلی نباشد. تنظیم اولویت باید با نقش واقعی آن سازگار باشد. بعد از failover نیز replicaهای دیگر باید به master تازه متصل شوند و عضو قبلی هنگام بازگشت نقش مناسب بگیرد. مشاهده این مرحله برای جلوگیری از برداشت اشتباه از وضعیت خوشه ضروری است.
پیکربندی Sentinel باید قابل نوشتن و پایدار باشد، زیرا اطلاعات کشف‌شده و تغییرات وضعیت در آن اهمیت دارند. اجرای فرایند با فایل کاملاً موقتی و دور ریختن تغییرات پس از restart می‌تواند رفتار مورد انتظار را مختل کند. در محیط کانتینری، مسیر ذخیره و مجوز آن را بررسی کنید. تنظیمات ثابت مدیریت‌شده و وضعیت پویا را با آگاهی از رفتار ابزار نگه دارید تا ابزار مدیریت پیکربندی، اطلاعات لازم را ناخواسته بازنویسی نکند.
شبکه، NAT و نشانی اعلام‌شده
در شبکه دارای NAT یا نگاشت پورت، نشانی‌ای که یک جزء به دیگران معرفی می‌کند ممکن است از همه نقاط قابل دسترسی نباشد. باز بودن اتصال از داخل همان میزبان کافی نیست. از دید Sentinelهای دیگر و مشتری واقعی، نشانی اعلام‌شده master، replica و Sentinel را بررسی کنید. خطای کشف معمولاً با تعویض timeout حل نمی‌شود اگر مقصد اساساً قابل مسیریابی نباشد. تنظیم announce باید با توپولوژی و قابلیت نسخه مورد استفاده هماهنگ باشد.
احراز هویت Sentinel با Redis و احراز هویت مشتری با Sentinel نیز باید جدا طراحی شود. دسترسی مدیریتی بیش از نیاز را صرفاً برای رفع سریع خطا ندهید. اگر از TLS یا ACL استفاده می‌کنید، مسیرهای کشف و بازپیکربندی را با همان محدودیت‌ها آزمایش کنید. ممکن است خواندن وضعیت سالم باشد ولی فرمان لازم برای تغییر نقش به علت مجوز رد شود. این نقص فقط هنگام حادثه آشکار می‌شود مگر آزمون failover کامل انجام شده باشد.
آزمایش خرابی با شواهد قابل مقایسه
در محیط آزمایش، ابتدا توقف فرایند master را بررسی کنید و سپس سناریوی جدا شدن شبکه را جدا اجرا کنید. این دو خرابی پیامد یکسانی ندارند؛ در جدایی شبکه ممکن است فرایند قدیمی هنوز زنده باشد. زمان تشخیص، زمان انتخاب master تازه، زمان اتصال مشتری و زمان بازگشت replicaها را مستقل ثبت کنید. اگر فقط نخستین پیام موفق Sentinel را زمان بازیابی بدانید، وقفه واقعی برنامه کمتر از واقع گزارش می‌شود.
در پایان تمرین، وضعیت هر نقش و شناسه داده را بررسی کنید. عضو قدیمی را با احتیاط برگردانید و مطمئن شوید به شکل مورد انتظار دنبال‌کننده شده است. اگر داده از دست رفته، آن را به عنوان محدودیت مشاهده‌شده ثبت کنید، نه اینکه با عبارت «خوشه سالم است» پنهان شود. همچنین persistence و پشتیبان را جدا نگه دارید؛ failover به replica جایگزین پشتیبان در برابر حذف منطقی داده نیست، زیرا حذف می‌تواند به replicaها نیز منتقل شود.
معیار انتخاب این معماری
Sentinel زمانی ارزشمند است که نیاز به هماهنگی failover و کشف master دارید و محدودیت‌های مدل replication را پذیرفته‌اید. پیش از گسترش، باید تیم بتواند توضیح دهد چه خرابی‌هایی تحمل می‌شوند، چه داده‌ای ممکن است از دست برود و مشتری چگونه دوباره وصل می‌شود. یک معماری کوچک با همین قراردادهای روشن می‌تواند قابل اتکاتر از تعداد زیادی replica و ناظر بدون آزمون باشد. تصمیم نهایی باید از نیاز داده و رفتار برنامه آغاز شود، نه فقط از سبز بودن وضعیت فرایندها.
