Rose در کارگاه نمایشی آکادمی ویونیکس، تکثیر Redis و سه رأی‌دهندهٔ Sentinel را بررسی می‌کند؛ تصویر ساختگی آموزشی.

WIUNIX ACADEMY

آموزش نصب Redis Sentinel در اوبونتو و دبیان

یک سرور نویسنده، دو نسخهٔ آماده‌به‌کار و سه رأی‌دهندهٔ مستقل بسازید؛ رسیدن داده، کشف مقصد، جابه‌جایی و بازیابی امن را بررسی کنید.

پیشرفته75 دقیقه مطالعهبه‌روزرسانی
محیطت را انتخاب کن

آموزش متناسب با محیط تو

کجا اجرا می‌کنی؟

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

Debian 12 LTSبررسی‌شده با مستندات رسمی ·

آموزش متناسب با مقادیر تو

تنظیمات این آموزش

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

ویرایش 5 مقدار این آموزش

از اینجا شروع کن

در پایان چه چیزی خواهی داشت؟

راه‌اندازی سه سرور Redis و Sentinel با TLS دوطرفه، نقش‌های مستقل، بررسی دادهٔ مقصد و تمرین جابه‌جایی و بازیابی با حفظ داده.

01A · نویسندهٔ اولیهRedis و Sentinel · دامنهٔ۱
02B · دریافت‌کنندهRedis و Sentinel · دامنهٔ۲
03C · دریافت‌کنندهRedis و Sentinel · دامنهٔ۳
سیستم‌عامل‌ها و نسخه‌های پوشش‌داده‌شده

بازبینی۲۰۲۶-۱۰-۲۰. پنج مسیر توزیع بر پایهٔ مستندات‌اند و آزمون نصب کامل نیستند. با Redis 7.0.15 موجود، سه نمونهٔ داده و سه Sentinel در شبکهٔ جدا برای TLS دوطرفه، ACL، دادهٔ مقصد، انتخابات پس از توقف سرویس، دادهٔ بعد از جابه‌جایی، بازگشت، بازنویسی تنظیمات، خروجی و بازیابی RDB و رد نوشتن بدون نسخهٔ همراه آزموده شدند. اجرای یک‌میزبانی استقلال دامنهٔ خرابی، نصب کامل، systemd، فایروال، کتابخانهٔ واقعی اپلیکیشن یا همهٔ سیستم‌عامل‌ها را ثابت نمی‌کند. پشتیبانی توزیع و بالادستی جداست. عکس‌ها نمایشی‌اند.

قبل از شروع

  • سه سرور systemd تازه با نسخهٔ یکسان سیستم‌عامل و بسته، دسترسی sudo و SSH، IP خصوصی و ساعت هماهنگ در دامنه‌های خرابی مستقل.
  • سیاست شبکهٔ محدود، میزبان مجاز کلاینت، مدیر اسرار محافظت‌شده و CA اختصاصی موجود با گواهی مستقل هر گره و گواهی جدا برای کلاینت.
  • دادهٔ قبلی Redis یا Valkey و نویسندهٔ اپلیکیشن وجود نداشته باشد. رم و دیسک کافی برای ذخیره‌سازی و بکاپ؛ میزبان بازیابی هم‌نسخه با قابلیت فضای نام شبکه و دسترسی ریشه.

یک سرور نویسنده و دو نسخهٔ آماده‌به‌کار

این آموزش برای سه سرور تازه و اختصاصی است: A با نشانی 10.20.0.10، B با 10.20.0.11 و C با 10.20.0.12. روی هر سرور، Redis روی پورت TLS 6379 و Sentinel روی TLS 26379 اجرا می‌شود. ابتدا A نویسنده است و دو سرور دیگر فقط داده را دریافت می‌کنند. نام گروه academy پس از تغییر سرور اصلی ثابت می‌ماند. رأی‌دهنده‌ها باید در سه دامنهٔ خرابی مستقل باشند؛ سه پردازش روی یک میزبان یا سه ماشین روی یک هایپروایزر چنین استقلالی ندارند. این ساختار برای یک مجموعه‌داده است و شاردینگ یا نوشتن هم‌زمان روی چند سرور را فراهم نمی‌کند.

رأی خرابی با مجوز جابه‌جایی فرق دارد

با حد نصاب ۲، دست‌کم دو Sentinel باید خرابی سرور اصلی را گزارش کنند. برای انتخاب رهبر جابه‌جایی نیز موافقت اکثریت تمام Sentinelهای شناخته‌شده لازم است؛ در این طرح دو رأی از سه رأی. یک رأی‌دهندهٔ تنها اجازهٔ ارتقا ندارد. تکثیر ناهم‌زمان است: حتی نوشتن تأییدشده ممکن است پس از ارتقا از دست برود و پاسخ نسخهٔ پشتیبان می‌تواند قدیمی باشد. WAIT فقط دریافت داده توسط نسخه‌ها را در همان اتصال بررسی می‌کند؛ تضمین ثبت پایدار یا اجماع نیست. ذخیره‌سازی AOF با فاصلهٔ یک ثانیه هم در خرابی ناگهانی ممکن است آخرین تغییرات محلی را از دست بدهد. Sentinel جای حصارگذاری شبکه یا بکاپ را نمی‌گیرد.

پیش از نصب، شبکه و دادهٔ قبلی روشن باشد

این مراحل برای راه‌اندازی تازه است، نه مهاجرت دادهٔ موجود. اگر بررسی اولیه نصب یا داده‌ای پیدا کرد، کار را متوقف کنید؛ پاک‌کردن آن برای عبور از کنترل مجاز نیست. نسخهٔ سیستم‌عامل و بسته‌ها روی سه سرور یکسان باشد. نشانی‌های نمونه و رابط ens 18 را با شبکهٔ واقعی جایگزین کنید. در فایروال یا گروه امنیتی با سیاست پیش‌فرض مسدود، پورت۶۳۷۹ فقط برای سه سرور و نشانی‌های مصوب اپلیکیشن و مدیر باز باشد. پورت۲۶۳۷۹ هم فقط به رأی‌دهنده‌ها و کلاینت‌های مجاز کشف سرویس دسترسی بدهد. قاعدهٔ محدود SSH حفظ شود. پیش از روشن‌کردن سرویس‌ها این کنترل‌ها را برقرار کنید؛ دسترسی عمومی و تغییر پورت با NAT در این طرح جایی ندارد.

نسخهٔ بالادستی، وصلهٔ توزیع و مجوز

در بازبینی۲۰۲۶-۱۰-۲۰، فهرست انتشار بالادستی شاخهٔ۸٫۱۰ را نشان می‌دهد، ولی مبنای بسته‌های انتخابی۸٫۰ یا۷٫۰ است. این دو شاخه در سیاست امنیتی بالادستی پشتیبانی نمی‌شوند؛ تصمیم نگهداری بستهٔ وصله‌شدهٔ توزیع جداست. استفادهٔ عملیاتی این راهنما مشروط به تأیید پوشش امنیتی بسته است، نه توصیه به اجرای باینری بدون نگهداری. مبدأ مخزن و وضعیت امنیتی بسته بررسی شود. مبنای۷٫۰ مجوز BSD-3-Clause دارد؛ Redis 8 گزینه‌های AGPLv 3 و RSALv 2 و SSPLv 1 را عرضه می‌کند. متن copyright بسته و تعهد مجوز انتخابی، به‌ویژه برای نسخهٔ تغییرکرده یا عرضهٔ میزبانی‌شده، باید بررسی شود. شرایط Cloud و Software خودکار به این بسته اعمال نمی‌شود. این راهنما مجموعهٔ ماژول نصب نمی‌کند.

01

قدم بعدی

بررسی سه سرور تازه

روی A و B و C با حساب مدیر دارای sudo اجرا شود. نسخهٔ سیستم‌عامل، نشانی خصوصی، همگام‌بودن ساعت و منابع را بررسی کنید؛ برای آزمایش کوچک دست‌کم۲ گیگابایت رم و فضای کافی برای داده، بازنویسی AOF و بکاپ لازم است. هر پردازشی روی پورت‌های۶۳۷۹ و۲۶۳۷۹ نیاز به بررسی دارد. نصب دستی ممکن است در فهرست بسته‌ها دیده نشود؛ خروجی پردازش‌ها و پورت‌ها نیز ملاک است.

Bash
(
set -euo pipefail
. /etc/os-release
printf '%s %s\n' "$ID" "$VERSION_ID"
dpkg --print-architecture
ip -br address
timedatectl status
df -h / /var
installed=$(dpkg-query -W -f='${binary:Package} ${db:Status-Status}\n')
if printf '%s\n' "$installed" | grep -E '^(redis-server|redis-sentinel|valkey-server|valkey-sentinel)(:[^ ]+)? installed$' >/dev/null; then
  echo 'Existing Redis/Valkey installation: STOP' >&2; exit 1
fi
for path in /etc/redis /var/lib/redis /var/lib/redis-sentinel; do
  if sudo test -e "$path"; then echo "Existing state: $path; STOP" >&2; exit 1; fi
done
sudo ss -lntp
)
از کجا بدانم درست انجام شد؟

هر سه سرور تازه‌اند و نشانی‌های خصوصی به آن‌ها اختصاص دارد.

02

قدم بعدی

نصب بسته‌های هم‌نسخه از مخزن سیستم‌عامل

پس از عبور از بررسی اولیه، روی هر سه سرور اجرا شود. APT اصالت فرادادهٔ امضاشده و هش بسته‌ها را بررسی می‌کند. فقط مخزن همین نسخهٔ سیستم‌عامل و به‌روزرسانی امنیتی آن به کار رود؛ جایگزینی باینری Valkey، آرشیو بالادستی یا مخزن نسخهٔ دیگر اوبونتو مناسب این راهنما نیست. نصب ممکن است سرویس محدود به loopback را روشن کند. بخش بعد فقط همین سرویس تازه و اختصاصی آموزش را متوقف می‌کند. شمارهٔ کامل بسته‌ها در سه سرور باید برابر باشد.

Bash
sudo apt-get update
sudo apt-get install redis-server redis-sentinel redis-tools openssl nano
dpkg-query -W redis-server redis-sentinel redis-tools
redis-server --version
redis-sentinel --version
redis-cli --version
از کجا بدانم درست انجام شد؟

نسخهٔ Redis و Sentinel در سه سرور یکسان است و بستهٔ بدون اعتبارسنجی نصب نشده است.

03

قدم بعدی

توقف نمونهٔ تازه و نگهداری تنظیمات اولیه

فقط روی سرورهای تازهٔ همین آموزش انجام شود؛ توقف Redis محیط عملیاتی مجاز نیست. نسخهٔ تنظیمات با ساختار مسیر نگهداری می‌شود. نبودن هر کدام از فایل‌ها خطاست. این آرشیو محرمانه است و نباید وارد گیت یا فضای عمومی شود.

Bash
sudo systemctl stop redis-sentinel redis-server
sudo bash -eu <<'BACKUP'
umask 077
test -f /etc/redis/redis.conf
test -f /etc/redis/sentinel.conf
install -d -m 0700 /root/academy-backups
backup=$(mktemp -d /root/academy-backups/redis-defaults-XXXXXXXX)
tar -C / -cpf "$backup/etc-redis.tar" etc/redis
tar -tf "$backup/etc-redis.tar" >/dev/null
tar -C / -df "$backup/etc-redis.tar"
printf 'Defaults retained: %s\n' "$backup"
BACKUP
از کجا بدانم درست انجام شد؟

دو سرویس اختصاصی متوقف‌اند و آرشیو تنظیمات خوانده و با منبع تطبیق داده شده است.

04

قدم بعدی

گواهی مستقل برای هر سرور

زیرساخت گواهی مورد اعتماد باید از قبل سه فایل ورودی را در مسیر محافظت‌شده گذاشته باشد. هر سرور کلید و گواهی جداگانه، SAN مطابق IP خصوصی خودش، کاربردهای serverAuth و clientAuth و زنجیرهٔ معتبر داشته باشد. کلید خصوصی CA به سرورها منتقل نشود و یک کلید برای سه سرور تکرار نشود. برای میزبان مدیر و اپلیکیشن هم گواهی کلاینت جدا صادر شود. mTLS اعتماد به CA را بررسی می‌کند و جای نام کاربری ACL را نمی‌گیرد. اعتبارسنجی CA در اتصال داخلی Redis و Sentinel را نباید بررسی نام میزبان نامید. CA اختصاصی این سامانه، مسیر خصوصی و محدودیت مبدأ لازم‌اند؛ کلاینتی که تطبیق نام مقصد می‌خواهد باید آن را صریح پشتیبانی و بررسی کند.

Bash
(
set -euo pipefail
sudo install -d -o root -g redis -m 0750 /etc/redis/tls
sudo install -o root -g redis -m 0640 /root/academy-pki/ca.pem /etc/redis/tls/ca.pem
sudo install -o root -g redis -m 0640 /root/academy-pki/node-fullchain.pem /etc/redis/tls/node.pem
sudo install -o root -g redis -m 0640 /root/academy-pki/node-key.pem /etc/redis/tls/node.key
sudo openssl verify -CAfile /etc/redis/tls/ca.pem -purpose sslserver /etc/redis/tls/node.pem
sudo openssl verify -CAfile /etc/redis/tls/ca.pem -purpose sslclient /etc/redis/tls/node.pem
sudo openssl x509 -in /etc/redis/tls/node.pem -noout -dates -ext subjectAltName
sudo openssl x509 -in /etc/redis/tls/node.pem -checkend 604800 -noout
sudo openssl x509 -in /etc/redis/tls/node.pem -pubkey -noout | openssl sha256
sudo openssl pkey -in /etc/redis/tls/node.key -pubout | openssl sha256
sudo -u redis test -r /etc/redis/tls/node.key
)
از کجا بدانم درست انجام شد؟

هر دو کاربرد گواهی معتبر است، SAN درست است، هش کلید عمومی برابر است و کاربر redis کلید را می‌خواند.

شش اعتبارنامه با مسئولیت جدا

در مدیر اسرار موجود، برای شش نقش رمزهای مستقل۶۴ نویسه‌ای هگز بسازید: ADMIN برای نگهداری، APP برای GET و SET و WAIT و بررسی سلامت و نقش در فضای academy:*، REPL برای تکثیر، CONTROL برای کنترل Redis توسط Sentinel، PEER برای ارتباط مدیریتی Sentinelها و DISCOVERY برای خواندن نشانی سرور اصلی. رمز هر نقش روی سه سرور یکسان است، اما بین نقش‌ها مشترک نباشد. عبارت‌های REPLACE_* نمونه‌اند و باید داخل ویرایشگر محافظت‌شده عوض شوند، نه در آرگومان فرمان. ضبط ترمینال و رهگیری شل هنگام ویرایش اسرار خاموش باشد. نمایش عمومی ACL و فایل تنظیمات هم امن نیست. رمز اتصال خروجی در تنظیمات محافظت‌شده لازم است؛ هش‌کردن ACL ورودی این نیاز را حذف نمی‌کند.

05

قدم بعدی

ویرایش فایل دسترسی Redis

روی هر سه سرور انجام شود. پنل بعد محتوای فایل است و فرمان شل نیست. چهار رمز نمونه را پیش از ذخیره عوض کنید. کاربر پیش‌فرض غیرفعال است. اپلیکیشن دسترسی Pub/Sub، به‌ویژه کانال رزروشدهٔ Sentinel، ندارد. مدیر اختیار نگهداری دارد ولی دسترسی اولیهٔ کانال ندارد؛ فقط CONTROL کانال داخلی را می‌گیرد.

Bash
sudo install -o root -g redis -m 0640 /dev/null /etc/redis/users.acl
sudo nano /etc/redis/users.acl
از کجا بدانم درست انجام شد؟

فایل محافظت‌شده برای محتوای ACL آماده است.

محتوای ACL سرور داده

محتوای یکسان روی A و B و C. حساب REPL با وجود نداشتن فرمان خواندن کلید، جریان کامل داده را دریافت می‌کند و رمز آن محرمانه است. CONTROL می‌تواند نقش سرور را تغییر دهد و تنظیمات را بازنویسی کند؛ این حساب برای اپلیکیشن نیست. دسترسی عمومی کانال به APP یا REPL داده نشود.

Redis ACL · /etc/redis/users.acl
user default off
user admin on >REPLACE_ADMIN_64_HEX ~* resetchannels +@all
user app on >REPLACE_APP_64_HEX ~academy:* resetchannels -@all +ping +role +get +set +wait
user repl on >REPLACE_REPL_64_HEX resetchannels -@all +ping +replconf +psync
user control on >REPLACE_CONTROL_64_HEX resetchannels &__sentinel__:hello -@all +multi +slaveof +ping +exec +subscribe +config|rewrite +role +publish +info +client|setname +client|kill +script|kill
همهٔ آموزش‌های آکادمی ↗