در دنیای برنامههای کاربردی مدرن، پایداری و دسترسپذیری بالا (High Availability) سرویسها از اهمیت حیاتی برخوردار است. ردیس (Redis) به عنوان یک پایگاه داده درون حافظهای (in-memory) پرسرعت، نقش کلیدی در بهبود عملکرد بسیاری از سیستمها ایفا میکند. با این حال، بروز خطا در یک نمونهی منفرد ردیس میتواند منجر به از دسترس خارج شدن کل سرویس و ایجاد اختلال در عملکرد برنامه شود.
ردیس سنتینل (Redis Sentinel) یک سیستم توزیعشده است که برای نظارت بر نمونههای ردیس و مدیریت خودکار فرآیند جابجایی خطا (failover) طراحی شده است. به عبارت سادهتر، سنتینل مانند یک نگهبان هوشیار عمل میکند که به طور مداوم سلامت سرور اصلی (master) و سرورهای پشتیبان (replicas) ردیس را بررسی میکند. در صورتی که سرور اصلی دچار مشکل شود و از دسترس خارج گردد، سنتینل به سرعت وارد عمل شده، یکی از سرورهای پشتیبان را به عنوان سرور اصلی جدید انتخاب کرده و تنظیمات سایر اجزا و کلاینتها را بهروزرسانی میکند تا به سرور اصلی جدید متصل شوند.
این فرآیند خودکار تضمین میکند که حتی در صورت بروز مشکل برای سرور اصلی، سرویس ردیس با حداقل وقفه به کار خود ادامه دهد و دسترسپذیری بالا برای برنامهی شما فراهم گردد. استفاده از سنتینل به شما کمک میکند تا از دادههای خود در برابر خرابیهای سختافزاری یا نرمافزاری محافظت کرده و تجربهی کاربری بهتری را برای کاربران نهایی به ارمغان بیاورید.
از کجا شروع کنیم؟
برای راهاندازی Redis Sentinel و ایجاد یک سیستم با دسترسپذیری بالا، باید چند مرحله اساسی را طی کنید و تعداد مناسبی ماشین (فیزیکی یا مجازی) در نظر بگیرید.
راهاندازی Redis Sentinel شامل مراحل زیر است:
- نصب Redis: ابتدا باید Redis را روی تمام ماشینهایی که قرار است به عنوان سرور Redis (master یا replica) یا به عنوان فرآیند Sentinel استفاده شوند، نصب کنید.
- پیکربندی نمونههای Redis برای تکثیر (Replication):
- یک سرور اصلی (Master): یک نمونه Redis را به عنوان سرور اصلی پیکربندی کنید. این سرور مسئولیت پردازش تمام عملیات نوشتن (write) را بر عهده خواهد داشت.
- یک یا چند سرور پشتیبان (Replica): یک یا چند نمونه دیگر Redis را به عنوان پشتیبان سرور اصلی پیکربندی کنید. این سرورها به صورت خودکار دادهها را از سرور اصلی کپی (replicate) میکنند و میتوانند برای پردازش عملیات خواندن (read) و همچنین برای جابجایی خطا (failover) استفاده شوند.
- پیکربندی و اجرای فرآیندهای Sentinel:
- فایلهای پیکربندی sentinel.conf را برای هر فرآیند Sentinel ایجاد و تنظیم کنید.
- در هر فایل پیکربندی، باید حداقل یک “monitor” تعریف کنید که به Sentinel بگوید کدام سرور اصلی را نظارت کند، آدرس IP و پورت آن، و تعداد Sentinelهایی که برای اعلام خرابی سرور اصلی (quorum) لازم است.
- فرآیندهای Sentinel را روی ماشینهای تعیین شده اجرا کنید.
- پیکربندی کلاینتها: برنامههای کاربردی خود را طوری پیکربندی کنید که به جای اتصال مستقیم به یک نمونه Redis خاص، از طریق Sentinelها به سرور اصلی فعلی متصل شوند. کتابخانههای کلاینت Redis معمولاً از این قابلیت پشتیبانی میکنند.
به چند ماشین نیاز داریم؟
تعداد ماشینهای مورد نیاز به میزان تحمل خطا و پیچیدگی مورد نظر شما بستگی دارد، اما در اینجا یک راهنمای کلی ارائه میشود:
-
حداقل برای یک مجموعه پایه (Basic Setup):
- ۳ ماشین: این حداقل تعداد توصیه شده برای یک راهاندازی پایدار Sentinel است. دلیل این امر جلوگیری از “split-brain” (وضعتی که گروهی از نودها ارتباطشان با گروه دیگر قطع شده و هر گروه فکر میکند دیگری از کار افتاده است) و داشتن quorum مناسب برای تصمیمگیری در مورد failover است.
- ماشین ۱: اجرای نمونه Redis اصلی (Master).
- ماشین ۲: اجرای یک نمونه Redis پشتیبان (Replica).
- ماشین ۳: اجرای فرآیند Sentinel. (میتوان Sentinel را روی یکی از ماشینهای Redis هم اجرا کرد، اما برای جداسازی بهتر است روی ماشین جداگانه باشد).
- نکته: در این سناریوی حداقل، اگر ماشین Sentinel از کار بیفتد، فرآیند failover خودکار کار نخواهد کرد.
- ۳ ماشین: این حداقل تعداد توصیه شده برای یک راهاندازی پایدار Sentinel است. دلیل این امر جلوگیری از “split-brain” (وضعتی که گروهی از نودها ارتباطشان با گروه دیگر قطع شده و هر گروه فکر میکند دیگری از کار افتاده است) و داشتن quorum مناسب برای تصمیمگیری در مورد failover است.
-
توصیه شده برای دسترسپذیری بالا و تحمل خطای خوب (Recommended for High Availability):
-
حداقل ۳ ماشین برای فرآیندهای Sentinel: برای اینکه Sentinel خودش یک نقطه شکست (Single Point of Failure – SPOF) نباشد و بتواند به درستی در مورد failover تصمیمگیری کند (رسیدن به quorum)، توصیه میشود حداقل ۳ فرآیند Sentinel روی ماشینهای مجزا اجرا شوند.
-
حداقل ۲ ماشین برای نمونههای Redis (۱ Master + ۱ Replica): این حداقل برای داشتن یک پشتیبان جهت failover است.
- ماشین ۱: نمونه Redis اصلی (Master) + یک فرآیند Sentinel.
- ماشین ۲: نمونه Redis پشتیبان (Replica) + یک فرآیند Sentinel.
- ماشین ۳: فقط یک فرآیند Sentinel.
-
یک راهاندازی متداول و مقاومتر:
- ماشین ۱: Redis Master
- ماشین ۲: Redis Replica 1
- ماشین ۳: Redis Replica 2 (اختیاری اما برای افزایش تحمل خطا و توزیع بار خواندن مفید است)
- ماشین ۴: Sentinel 1
- ماشین ۵: Sentinel 2
- ماشین ۶: Sentinel 3
-
نکات کلیدی در مورد تعداد ماشینها:
- Quorum: برای اینکه Sentinel بتواند یک failover را آغاز کند، باید تعداد مشخصی از فرآیندهای Sentinel (که به آن quorum گفته میشود) با از کار افتادن master موافق باشند. مقدار quorum در فایل پیکربندی Sentinel تنظیم میشود (sentinel monitor <master-name> <ip> <port> <quorum>). معمولاً این مقدار (تعداد کل Sentinel ها / ۲) + ۱ در نظر گرفته میشود تا اکثریت آرا را داشته باشد. بنابراین، برای داشتن یک سیستم قابل اعتماد، باید تعداد فردی از Sentinel ها (مثلاً ۳، ۵، …) داشته باشید.
- جداسازی فیزیکی/منطقی: تا حد امکان، نمونههای Redis (master/replica) و فرآیندهای Sentinel را روی ماشینهای فیزیکی یا مجازی مجزا و حتی در صورت امکان در Availability Zone های مختلف (در محیطهای ابری) قرار دهید تا از خرابی همزمان به دلیل مشکلات سختافزاری یا شبکه در یک نقطه جلوگیری شود.
- منابع ماشین: هر نمونه Redis و هر فرآیند Sentinel به منابع CPU، حافظه و شبکه نیاز دارد. فرآیندهای Sentinel معمولاً منابع زیادی مصرف نمیکنند، اما نمونههای Redis، به خصوص Master، ممکن است بسته به حجم داده و بار کاری، به حافظه و CPU قابل توجهی نیاز داشته باشند.
راهاندازی Redis Sentinel در اوبونتو (Ubuntu) برای ۳ ماشین مجزا
این راهنما فرض میکند که شما ۵ ماشین مجازی یا فیزیکی با سیستمعامل اوبونتو در اختیار دارید:
- ۲ ماشین برای نودهای Redis: یکی به عنوان Master و دیگری به عنوان Replica.
- ۳ ماشین برای فرآیندهای Redis Sentinel: هر کدام در یک نقطه متفاوت برای افزایش تحمل خطا.
هدف ما پیکربندی ۳ فرآیند Sentinel است که نود Master را نظارت کرده و در صورت بروز مشکل، فرآیند failover به نود Replica را مدیریت کنند.
پیشنیازها:
نصب Redis روی تمام ۵ ماشین:
#apt update
#apt install redis-server
پس از نصب، سرویس Redis به طور خودکار اجرا میشود. برای نودهای Sentinel، ما فقط به ابزار redis-sentinel نیاز داریم که با همین پکیج نصب میشود. برای جلوگیری از اجرای غیرضروری سرویس کامل Redis روی ماشینهای Sentinel (اگر فقط برای Sentinel استفاده میشوند)، میتوانید سرویس redis-server را روی آن ماشینها غیرفعال و متوقف کنید:
#systemctl stop redis-server
#systemctl disable redis-server
پیکربندی Master و Replica:
-
- ماشین Master (مثلاً IP: 192.168.1.10):
- فایل redis.conf (معمولاً در /etc/redis/redis.conf) را ویرایش کنید:
- bind 0.0.0.0 (یا IP مشخص ماشین Master که از بیرون قابل دسترسی باشد)
- مقدار تنظیم شده برای requirepass را بررسی کنید. این همان پسوردی است که باید در masterauth سرور پشتیبان استفاده شود.
- فایل redis.conf (معمولاً در /etc/redis/redis.conf) را ویرایش کنید:
- ماشین Replica (مثلاً IP: 192.168.1.11):
- فایل redis.conf را ویرایش کنید:
- bind 0.0.0.0 (یا IP مشخص ماشین Replica)
- replicaof 192.168.1.10 6379 (IP و پورت Master)
- (اگر برای Master پسورد تنظیم کردهاید) masterauth YOUR_MASTER_PASSWORD
- (اختیاری ولی توصیه شده) requirepass YOUR_REPLICA_PASSWORD (میتواند با پسورد Master متفاوت باشد)
- فایل redis.conf را ویرایش کنید:
- سرویس Redis را روی ماشینهای Master و Replica ریاستارت کنید:
- ماشین Master (مثلاً IP: 192.168.1.10):
#systemctl restart redis-server
-
- با اتصال به Replica از طریق redis-cli و اجرای دستور INFO replication از صحت عملکرد تکثیر مطمئن شوید. role باید slave (یا replica) و master_link_status باید up باشد.
مرحله ۱: پیکربندی فایلهای Sentinel
روی هر یک از سه ماشین Sentinel (مثلاً با IP های ۱۹۲.۱۶۸.۱.۲۰, ۱۹۲.۱۶۸.۱.۲۱, ۱۹۲.۱۶۸.۱.۲۲)، یک فایل پیکربندی برای Sentinel ایجاد کنید. نام پیشفرض sentinel.conf است. میتوانید آن را در /etc/redis/ ایجاد کنید یا یک دایرکتوری جداگانه برای آن در نظر بگیرید.
محتویات فایل sentinel.conf برای هر سه ماشین Sentinel بسیار شبیه به هم خواهد بود، به خصوص بخش sentinel monitor.
#vim /etc/redis/sentinel.conf
sentinel.conf
port 26379
dir “/var/lib/redis”
sentinel monitor mymaster 192.168.1.10 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
# sentinel auth-pass mymaster YOUR_MASTER_PASSWORD
logfile “/var/log/redis/sentinel.log”
# daemonize yes
نکات مهم برای فایل پیکربندی:
- مقدار sentinel monitor mymaster 192.168.1.10 6379 2 در فایل sentinel.conf هر سه ماشین Sentinel باید یکسان باشد. اینگونه Sentinelها یکدیگر را شناسایی کرده و در مورد وضعیت Master به توافق میرسند.
- آدرس IP استفاده شده در sentinel monitor (192.168.1.10) باید آدرس IP واقعی و قابل دسترسی سرور Master شما باشد.
- مقدار quorum برابر با ۲ به این معنی است که حداقل دو Sentinel از سه Sentinel باید تشخیص دهند که Master از کار افتاده تا فرآیند failover آغاز شود. این از تصمیمگیریهای نادرست در صورت مشکلات شبکهای موقت برای یک Sentinel جلوگیری میکند.
- اگر برای Master یا Replica پسورد (requirepass) تنظیم کردهاید، حتماً از sentinel auth-pass mymaster YOUR_MASTER_PASSWORD (و در صورت لزوم دستورات مشابه برای احراز هویت با replicaها اگر آنها نیز پسورد دارند و Sentinel نیاز به تغییر تنظیماتشان دارد) استفاده کنید.
مرحله ۲: ایجاد سرویس Systemd برای Sentinel
برای مدیریت آسانتر فرآیند Sentinel (شروع، توقف، ریاستارت و اجرای خودکار پس از بوت)، بهتر است یک سرویس systemd برای آن ایجاد کنید.
روی هر یک از سه ماشین Sentinel، یک فایل سرویس در مسیر زیر با محتوای زیر ایجاد کنید:
#vim /etc/systemd/system/redis-sentinel.service
redis-sentinel.service
[Unit] Description=Redis Sentinel
After=network.target
[Service] User=redis
Group=redis
ExecStart=/usr/bin/redis-server /etc/redis/sentinel.conf –sentinel
ExecStop=/bin/kill -s TERM $MAINPID
Restart=always
[Install] WantedBy=multi-user.target
#chown redis:redis sentinel.conf
#touch /var/log/redis/sentinel.log
#chown redis:adm /var/log/redis/sentinel.log
#systemctl daemon-reload
#systemctl start redis-sentinel
#systemctl enable redis-sentinel
مرحله ۳: بررسی وضعیت Sentinel ها
پس از اجرای Sentinel ها روی سه ماشین، میتوانید وضعیت آنها و نظارت بر Master را بررسی کنید. روی هر یک از ماشینهای Sentinel، از redis-cli برای اتصال به پورت Sentinel (پیشفرض ۲۶۳۷۹) استفاده کنید:
#redis-cli -p 26379
سپس دستورات زیر را وارد کنید:
- ping: باید پاسخ PONG دریافت کنید.
- sentinel masters: اطلاعات Master تحت نظارت را نشان میدهد. باید نام mymaster و وضعیت آن را ببینید. به فیلدهای num-slaves (باید ۱ باشد) و num-other-sentinels (باید ۲ باشد، نشاندهنده دو Sentinel دیگر) توجه کنید.
- sentinel slaves mymaster: اطلاعات Replica(های) مربوط به mymaster را نشان میدهد.
- sentinel sentinels mymaster: اطلاعات سایر Sentinelهایی که mymaster را نظارت میکنند، نشان میدهد.
همچنین میتوانید لاگ فایل Sentinel (مثلاً /var/log/redis/sentinel.log) را برای مشاهده پیامها و رویدادها بررسی کنید. شما باید پیامهایی مبنی بر شناسایی Master، Replica و سایر Sentinelها مشاهده کنید.
مرحله ۴: تست Failover (اختیاری اما مهم)
برای اطمینان از صحت عملکرد، میتوانید فرآیند failover را تست کنید:
- شبیهسازی خرابی Master: سرویس Redis را روی ماشین Master متوقف کنید:
#systemctl stop redis-server
- مشاهده لاگهای Sentinel: لاگهای Sentinelها را دنبال کنید. باید ببینید که آنها Master را به عنوان +sdown (subjectively down) و سپس +odown (objectively down) علامتگذاری میکنند. سپس فرآیند انتخاب Master جدید (failover) آغاز میشود. یکی از Sentinelها به عنوان رهبر انتخاب شده و Replica را به Master ارتقا میدهد.
- بررسی Master جدید: پس از چند لحظه (بسته به تنظیمات down-after-milliseconds و failover-timeout)، با استفاده از redis-cli -p 26379 و سپس sentinel master mymaster روی یکی از Sentinelها، باید ببینید که آدرس IP و پورت Master تغییر کرده و به آدرس Replica قبلی اشاره میکند.
- بررسی Replica جدید: Replica قبلی اکنون باید به عنوان Master جدید (role:master در INFO replication) و Master قبلی (اگر دوباره آنلاین شود) به عنوان Replica آن شناخته شود (یا حداقل Sentinelها تلاش میکنند آن را به عنوان Replica پیکربندی کنند).
- بازگرداندن Master قبلی: سرویس Redis را روی ماشین Master اصلی دوباره راهاندازی کنید:
#systemctl start redis-server
Sentinelها باید تشخیص دهند که Master قبلی برگشته و آن را به عنوان یک Replica برای Master جدید پیکربندی کنند.
با انجام این مراحل، شما یک سیستم Redis با دسترسپذیری بالا با استفاده از سه Sentinel مجزا خواهید داشت. کلاینتهای شما باید طوری پیکربندی شوند که از Sentinel برای پیدا کردن آدرس Master فعلی استفاده کنند. اکثر کتابخانههای کلاینت Redis این قابلیت را پشتیبانی میکنند.
