WIUNIX ACADEMY
آموزش نصب Redis Sentinel در اوبونتو و دبیان
صفحهٔ 2 از 4؛ مراحل قبلی و پیش‌نیازها را پیش از ادامه مرور کن.
آموزش متناسب با محیط تو
کجا اجرا می‌کنی؟
سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.
آموزش متناسب با مقادیر تو
تنظیمات این آموزش
مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر می‌کنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری می‌شوند و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شوند. پیش از اجرا، DNS، گواهی‌ها و سیاست شبکهٔ واقعی را بررسی کن.
ویرایش 5 مقدار این آموزش
قدم بعدی
تنظیم Redis با امکان بازنویسی نقش
روی سه سرور، فایل بسته با تنظیمات اختصاصی پنل بعد جایگزین شود. نشانی محلی A همان10.20.0.10 است؛ در B هر دو مقدار bind و announce به10.20.0.11 و در C به10.20.0.12 تغییر کند. رمز REPL با ACL برابر باشد و روی A هم تنظیم شود تا پس از جابه‌جایی بتواند نسخهٔ دریافت‌کننده شود. فایل باید برای بازنویسی نقش توسط Sentinel قابل نوشتن بماند. نسخهٔ اولیهٔ بسته را حفظ کنید.
sudo nano /etc/redis/redis.conf
نشانی محلی درست و رمز تکثیر آماده شده‌اند.
محتوای تنظیمات و بودجهٔ حافظه
حد۲۵۶ مگابایت فقط برای آزمایش کوچک است. حافظهٔ جدا برای پردازش، بافر کلاینت، تکثیر و کپی هنگام ذخیره‌سازی لازم است. سیاست noeviction به‌جای حذف کلید، نوشتن جدید را رد می‌کند. شرط یک نسخهٔ همراه، بخشی از نوشتن روی سرور جداافتاده را پس از۱۰ ثانیه محدود می‌کند؛ حصار فوری یا تضمین نبود اتلاف نیست. وجود سه سرور داده باعث می‌شود پس از خرابی یک میزبان، نویسندهٔ تازه هنوز یک نسخهٔ دریافت‌کننده داشته باشد. با فقط دو سرور داده، همین سیاست تا بازگشت سرور دیگر نوشتن را متوقف می‌کند.
bind 127.0.0.1 10.20.0.10
protected-mode yes
port 0
tls-port 6379
tls-cert-file /etc/redis/tls/node.pem
tls-key-file /etc/redis/tls/node.key
tls-ca-cert-file /etc/redis/tls/ca.pem
tls-auth-clients yes
tls-protocols "TLSv1.2 TLSv1.3"
tls-replication yes
daemonize no
supervised systemd
pidfile /run/redis/redis-server.pid
logfile /var/log/redis/redis-server.log
dir /var/lib/redis
dbfilename dump.rdb
save 900 1
appendonly yes
appendfsync everysec
maxmemory 256mb
maxmemory-policy noeviction
aclfile /etc/redis/users.acl
masteruser repl
masterauth REPLACE_REPL_64_HEX
replica-announce-ip 10.20.0.10
replica-announce-port 6379
replica-read-only yes
replica-serve-stale-data no
min-replicas-to-write 1
min-replicas-max-lag 10
مبدأ اولیه فقط برای B و C
فقط در B و C این خط به همان فایل تنظیمات اضافه شود. در راه‌اندازی اولیه، A نباید این خط را داشته باشد. پس از جابه‌جایی، نقش و نشانی بازنویسی‌شده را Sentinel مدیریت می‌کند؛ اجرای دوبارهٔ فایل اولیه می‌تواند توپولوژی درست را خراب کند.
replicaof 10.20.0.10 6379
قدم بعدی
تفکیک مدیر Sentinel از کلاینت کشف سرویس
روی سه سرور. فایل بعد دسترسی مدیر و همتای Sentinel را از کشف سرویس جدا می‌کند. PEER طبق قرارداد بالادستی اختیار مدیریتی دارد و نباید به اپلیکیشن داده شود. در این روش ACL، تنظیم requirepass هم‌زمان اضافه نمی‌شود.
sudo install -o root -g redis -m 0640 /dev/null /etc/redis/sentinel-users.acl
sudo nano /etc/redis/sentinel-users.acl
فایل مجزای محافظت‌شده آماده است.
محتوای ACL برای Sentinel
نام نقش‌ها و رمز هر نقش روی سه سرور برابر است. DISCOVERY امکان درخواست جابه‌جایی یا تغییر تنظیمات ندارد. رمز ADMIN برای نگهداری است؛ PEER با CONTROL سرور داده اشتباه نشود.
user default off
user admin on >REPLACE_ADMIN_64_HEX allchannels +@all
user peer on >REPLACE_PEER_64_HEX allchannels +@all
user discovery on >REPLACE_DISCOVERY_64_HEX -@all +auth +client|getname +client|id +client|setname +command +hello +ping +role +sentinel|get-master-addr-by-name +sentinel|master +sentinel|myid +sentinel|replicas +sentinel|sentinels +sentinel|masters
قدم بعدی
تنظیم نشانی و رأی‌دهی Sentinel
فایل Sentinel اختصاصی با پنل بعد جایگزین شود. در B و C هر دو نشانی bind و sentinel announce-ip، نشانی همان میزبان باشند؛ مبدأ نظارت اولیه در هر سه A است. رمز CONTROL با ACL داده و PEER با ACL رأی‌دهنده برابر باشد. فایل و پوشهٔ آن باید بازنویسی اتمی را اجازه دهند؛ فقط‌خواندنی‌کردن یا برگرداندن فایل اولیه بعد از انتخابات درست نیست.
sudo nano /etc/redis/sentinel.conf
هر رأی‌دهنده نشانی قابل دسترس مستقل و تنظیمات مشترک گروه و احراز هویت دارد.
محتوای تنظیمات رأی‌دهنده
زمان۱۰ ثانیه برای تشخیص اولیه است، نه تعهد زمان بازیابی. انتخابات، انتخاب نسخهٔ مناسب، همگام‌سازی و اتصال دوبارهٔ اپلیکیشن زمان بیشتری می‌خواهند. parallel-syncs با مقدار۱ تعداد دریافت‌کننده‌های در حال بازهمگام‌سازی را محدود می‌کند. فعال‌بودن tls-replication ارتباط رأی‌دهنده‌ها و اتصال آن‌ها به Redis را نیز TLS می‌کند.
bind 127.0.0.1 10.20.0.10
protected-mode yes
port 0
tls-port 26379
tls-cert-file /etc/redis/tls/node.pem
tls-key-file /etc/redis/tls/node.key
tls-ca-cert-file /etc/redis/tls/ca.pem
tls-auth-clients yes
tls-protocols "TLSv1.2 TLSv1.3"
tls-replication yes
daemonize no
supervised systemd
pidfile /run/sentinel/redis-sentinel.pid
logfile /var/log/redis/redis-sentinel.log
dir /var/lib/redis
aclfile /etc/redis/sentinel-users.acl
sentinel announce-ip 10.20.0.10
sentinel announce-port 26379
sentinel monitor academy 10.20.0.10 6379 2
sentinel auth-user academy control
sentinel auth-pass academy REPLACE_CONTROL_64_HEX
sentinel sentinel-user peer
sentinel sentinel-pass REPLACE_PEER_64_HEX
sentinel down-after-milliseconds academy 10000
sentinel failover-timeout academy 180000
sentinel parallel-syncs academy 1
قدم بعدی
کنترل مجوز و باقی‌نماندن مقدار نمونه
قبل از روشن‌کردن سرویس روی سه سرور اجرا شود. مالک دو فایل قابل بازنویسی redis است؛ فایل‌های ACL ریشه‌مالک می‌مانند. پوشهٔ تنظیمات بخشی از وضعیت حساس اجراست و نباید با استقرار گیت بازنویسی شود. محدودیت سرویس باید نوشتن در این مسیر را مجاز بداند؛ سخت‌سازی واحد را کورکورانه غیرفعال نکنید. محتوای محرمانهٔ فایل‌ها چاپ نشود.
(
set -euo pipefail
sudo chown redis:redis /etc/redis /etc/redis/redis.conf /etc/redis/sentinel.conf
sudo chmod 0750 /etc/redis
sudo chmod 0640 /etc/redis/redis.conf /etc/redis/sentinel.conf
sudo chown root:redis /etc/redis/users.acl /etc/redis/sentinel-users.acl
sudo chmod 0640 /etc/redis/users.acl /etc/redis/sentinel-users.acl
if sudo grep -E 'REPLACE_' /etc/redis/redis.conf /etc/redis/sentinel.conf /etc/redis/users.acl /etc/redis/sentinel-users.acl >/dev/null; then
echo 'Unfilled secret placeholder: STOP' >&2; exit 1
else
status=$?
test "$status" -eq 1
fi
sudo -u redis test -w /etc/redis
sudo -u redis test -w /etc/redis/redis.conf
sudo -u redis test -w /etc/redis/sentinel.conf
systemctl show redis-server redis-sentinel -p User -p Group -p ExecStart -p ReadWritePaths -p ReadWriteDirectories -p RuntimeDirectory
sudo ss -lntp
)
مقدار نمونه باقی نمانده، بازنویسی مجاز است و مسیر واحد با بستهٔ انتخابی برابر است.
قدم بعدی
راه‌اندازی Redis روی سه میزبان اختصاصی
ابتدا A و سپس B و C روشن شوند. این اولین شروع با تنظیمات تازه است. فقط پورت TLS ۶۳۷۹ روی loopback و IP خصوصی انتخابی دیده شود. اگر شروع شکست خورد، پیش از تکرار علت را بخوانید؛ Redis فرمان عمومی بررسی آفلاین تنظیمات مشابه nginx -t ندارد.
sudo systemctl enable --now redis-server
sudo systemctl status redis-server --no-pager
sudo ss -lntp
هر سه سرویس فعال‌اند و پورت متن ساده یا عمومی ندارند.
قدم بعدی
ورود مدیر برای بررسی تکثیر واقعی
روی هر سه سرور، رمز ADMIN در ورودی مخفی داده شود. رمز در آرگومان یا تاریخچهٔ شل قرار نگیرد. پنل بعد نشست تعاملی redis-cli است و نباید در شل اجرا شود.
sudo redis-cli --tls --cacert /etc/redis/tls/ca.pem --cert /etc/redis/tls/node.pem --key /etc/redis/tls/node.key -h 127.0.0.1 -p 6379 --user admin --askpass
نشست TLS احراز هویت‌شده باز می‌شود.
قدم بعدی
بررسی نقش، اتصال و پیشرفت دریافت داده
در A نقش master و دو connected_slaves انتظار می‌رود. در B و C نقش slave، مبدأ10.20.0.10، وضعیت اتصال up و مقدار صفر برای master_sync_in_progress لازم است. هنگام نوشتن، پیشرفت offset را هم ببینید؛ اتصال سالم به‌تنهایی رسیدن دادهٔ مورد نظر را ثابت نمی‌کند. خروجی Redis هنوز بعضی نام‌های قدیمی master و slave را دارد. ذخیره‌سازی هم نباید خطای تکرارشونده داشته باشد.
ROLE
INFO replication
INFO persistence
QUIT
نقش، مقدار دقیق و پاسخ مشخص‌شده در توضیح همین مرحله بررسی شود؛ نتیجهٔ غیرمنتظره ادامهٔ کار را متوقف می‌کند.