دانلود کتاب آموزشی نصب و پیکربندی کلاسترینگ سرویس های شبکه در لینوکس جلد اول

[cdb_course_lessons title=”بخش 1. مقدمه‌ای بر High Availability و Clustering”][cdb_course_lesson][/cdb_course_lesson][cdb_course_lesson title=”فصل 1. تعریف High Availability (HA)”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مفهوم High Availability (HA) و اهمیت آن در محیط‌های تجاری” subtitle=”توضیحات کامل”]High Availability یا دسترس‌پذیری بالا مفهومی در معماری سیستم‌های فناوری اطلاعات است که به تضمین عملکرد مداوم و بدون وقفه یک سرویس، سیستم یا شبکه اشاره دارد. در محیط‌های تجاری، سیستم‌هایی که High Availability دارند، حداقل زمان خرابی (Downtime) را تجربه می‌کنند و در برابر نقص‌های سخت‌افزاری، نرم‌افزاری و خطاهای انسانی مقاوم‌تر هستند.

---

اهمیت HA در محیط‌های تجاری

در دنیای دیجیتال امروزی، هرگونه قطعی یا اختلال در سیستم‌ها می‌تواند منجر به زیان‌های مالی و کاهش اعتماد مشتریان شود. برخی از دلایل اهمیت HA در کسب‌وکارها عبارت‌اند از:

• افزایش پایداری و قابلیت اطمینان: سیستم‌های HA طوری طراحی می‌شوند که در صورت خرابی یک بخش، عملیات به‌طور خودکار به یک بخش دیگر منتقل شود تا اختلالی در سرویس‌دهی ایجاد نشود.
• کاهش هزینه‌های ناشی از Downtime: هر دقیقه قطعی یک سرویس آنلاین می‌تواند هزینه‌های هنگفتی به سازمان تحمیل کند. HA باعث حداقل شدن زمان خرابی و کاهش خسارت‌های مالی می‌شود.
• بهبود تجربه کاربری: مشتریان انتظار دارند سرویس‌ها همیشه در دسترس باشند. HA کیفیت خدمات را حفظ کرده و رضایت کاربران را افزایش می‌دهد.
• افزایش امنیت داده‌ها: HA معمولاً با مکانیزم‌های Redundancy و Replication همراه است که از از بین رفتن داده‌ها جلوگیری کرده و دسترسی به اطلاعات را تضمین می‌کند.
• الزامات قانونی و قراردادی: بسیاری از شرکت‌ها باید SLA (Service Level Agreement) مشخصی را رعایت کنند که HA نقش کلیدی در برآورده کردن این تعهدات دارد.

---

نحوه پیاده‌سازی HA در زیرساخت‌های فناوری اطلاعات

برای دستیابی به High Availability، سازمان‌ها از معماری‌های پیشرفته و استراتژی‌های مختلفی استفاده می‌کنند که برخی از آنها عبارت‌اند از:

• Load Balancing (توزیع بار): استفاده از Load Balancer برای توزیع ترافیک بین چندین سرور به‌منظور جلوگیری از بارگذاری بیش‌ازحد روی یک سرور خاص.
• Clustering (کلاسترینگ): پیاده‌سازی سیستم‌های خوشه‌ای که در صورت خرابی یک سرور، بلافاصله سرور دیگری جایگزین آن شود.
• Replication (تکثیر داده‌ها): ذخیره‌سازی هم‌زمان داده‌ها در چندین سرور برای افزایش افزونگی (Redundancy) و جلوگیری از از دست رفتن اطلاعات.
• Failover Mechanisms (مکانیسم‌های انتقال خودکار): در صورت خرابی یک سرویس، سیستم به‌طور خودکار به یک سرویس پشتیبان منتقل می‌شود تا کاربران قطعی را تجربه نکنند.
• RAID (ذخیره‌سازی افزونه‌ای): استفاده از RAID برای محافظت از داده‌ها در صورت خرابی یک یا چند دیسک سخت.

---

پیاده‌سازی HA در سرورهای لینوکسی

یکی از روش‌های مهم برای پیاده‌سازی HA در سیستم‌های لینوکسی، استفاده از ابزارهای متن‌باز و قدرتمند است. برخی از مهم‌ترین ابزارها و تنظیمات در این زمینه عبارت‌اند از:

۱. پیکربندی Load Balancing با Nginx

فایل تنظیمات Nginx برای توزیع بار بین چندین سرور:

مسیر فایل: /etc/nginx/nginx.conf

sudo nano /etc/nginx/nginx.conf

افزودن تنظیمات توزیع بار:

upstream backend_servers {
    server 192.168.1.101;
    server 192.168.1.102;
    server 192.168.1.103;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend_servers;
    }
}

اعمال تغییرات و راه‌اندازی مجدد Nginx:

sudo systemctl restart nginx

---

۲. راه‌اندازی Failover با Keepalived

نصب Keepalived:

sudo apt install keepalived -y

پیکربندی Keepalived برای تنظیم یک IP مجازی:

مسیر فایل: /etc/keepalived/keepalived.conf

sudo nano /etc/keepalived/keepalived.conf

افزودن تنظیمات:

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass securepassword
    }
    virtual_ipaddress {
        192.168.1.200
    }
}

راه‌اندازی مجدد سرویس Keepalived:

sudo systemctl restart keepalived

---

جمع‌بندی

High Availability (HA) یکی از مهم‌ترین اصول در طراحی زیرساخت‌های فناوری اطلاعات در محیط‌های تجاری است که پایداری، کاهش هزینه‌های ناشی از Downtime، افزایش امنیت داده‌ها و بهبود تجربه کاربری را تضمین می‌کند. برای پیاده‌سازی HA، از مکانیزم‌هایی مانند Load Balancing، Clustering، Failover و Replication استفاده می‌شود. در سرورهای لینوکسی، ابزارهایی مانند Nginx، Keepalived و RAID امکان پیاده‌سازی HA را به‌صورت کامندی و خودکار فراهم می‌کنند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”اهداف High Availability (HA)” subtitle=”توضیحات کامل”]High Availability یا دسترس‌پذیری بالا یکی از اصول کلیدی در طراحی زیرساخت‌های فناوری اطلاعات است که با هدف به حداقل رساندن خرابی‌ها و افزایش پایداری سیستم‌ها پیاده‌سازی می‌شود.

برخی از مهم‌ترین اهداف HA عبارت‌اند از:

---

۱. کاهش زمان خرابی (Minimizing Downtime)

Downtime یا زمان خرابی به دوره‌ای اشاره دارد که یک سیستم، سرور یا سرویس قادر به ارائه خدمات نیست. HA با استفاده از سیستم‌های افزونه‌ای (Redundancy) و مکانیزم‌های Failover، احتمال بروز خرابی را کاهش داده و در صورت وقوع مشکلات، بلافاصله سرویس‌های جایگزین را فعال می‌کند.

راهکارهای کاهش Downtime در لینوکس:

مثال: مانیتورینگ و راه‌اندازی مجدد خودکار سرویس‌ها

یکی از روش‌های رایج برای کاهش زمان خرابی، استفاده از Systemd برای نظارت بر سرویس‌های حیاتی و راه‌اندازی مجدد آن‌ها در صورت خرابی است.

مسیر فایل: /etc/systemd/system/my_service.service

sudo nano /etc/systemd/system/my_service.service

افزودن تنظیمات نظارت خودکار:

[Unit]
Description=My Critical Service
After=network.target

[Service]
ExecStart=/usr/bin/my_service
Restart=always
RestartSec=5s

[Install]
WantedBy=multi-user.target

فعال‌سازی و راه‌اندازی مجدد سرویس:

sudo systemctl daemon-reload
sudo systemctl enable my_service
sudo systemctl start my_service

---

۲. جلوگیری از قطعی‌ها (Preventing Outages)

قطعی‌های ناگهانی سیستم‌ها می‌توانند عملکرد سازمان را مختل کرده و موجب از دست رفتن داده‌ها یا کاهش اعتماد کاربران شوند. HA با استفاده از روش‌هایی مانند Load Balancing، Clustering و Replication احتمال بروز چنین قطعی‌هایی را کاهش می‌دهد.

مثال: استفاده از HAProxy برای جلوگیری از قطعی‌ها

نصب HAProxy:

sudo apt install haproxy -y

پیکربندی Load Balancing برای جلوگیری از قطعی:

مسیر فایل: /etc/haproxy/haproxy.cfg

sudo nano /etc/haproxy/haproxy.cfg

افزودن تنظیمات:

frontend http_front
    bind *:80
    default_backend web_servers

backend web_servers
    balance roundrobin
    server web1 192.168.1.101:80 check
    server web2 192.168.1.102:80 check
    server web3 192.168.1.103:80 check

اعمال تغییرات و راه‌اندازی HAProxy:

sudo systemctl restart haproxy

---

۳. افزایش پایداری سیستم‌ها (Enhancing System Stability)

پایداری سیستم‌ها به میزان قابلیت اطمینان و عملکرد بدون مشکل آنها در طولانی‌مدت اشاره دارد. HA نقش مهمی در ایجاد یک محیط مقاوم در برابر خرابی‌ها و تحمل‌پذیر در برابر خطاها ایفا می‌کند.

مثال: استفاده از RAID برای افزایش پایداری ذخیره‌سازی

RAID (Redundant Array of Independent Disks) یکی از روش‌های رایج برای افزایش پایداری و جلوگیری از از دست رفتن داده‌ها است.

ایجاد یک RAID 1 (Mirror) برای محافظت از داده‌ها:

sudo mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc

افزودن RAID به فایل تنظیمات برای راه‌اندازی خودکار در بوت:

sudo mdadm --detail --scan >> /etc/mdadm/mdadm.conf

به‌روزرسانی initramfs برای شناسایی RAID در هنگام بوت:

sudo update-initramfs -u

---

جمع‌بندی

اهداف High Availability شامل کاهش زمان خرابی، جلوگیری از قطعی‌ها و افزایش پایداری سیستم‌ها است. پیاده‌سازی HA در محیط‌های لینوکسی با استفاده از ابزارهایی مانند Systemd، HAProxy، RAID و Load Balancing به سازمان‌ها کمک می‌کند تا سرویس‌های پایدار، مقاوم در برابر خطا و همیشه در دسترس داشته باشند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 2. نیاز به High Availability در سازمان‌ها”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”اهمیت High Availability (HA) برای اطمینان از دسترسی مداوم به سرویس‌ها و اپلیکیشن‌ها” subtitle=”توضیحات کامل”]در دنیای فناوری اطلاعات، دسترسی مداوم (Continuous Availability) به سرویس‌ها و اپلیکیشن‌ها از اهمیت بالایی برخوردار است. هر گونه اختلال یا خرابی در سیستم‌ها می‌تواند منجر به از دست رفتن داده‌ها، کاهش بهره‌وری و آسیب به اعتبار کسب‌وکار شود.

High Availability (HA) با استفاده از سیستم‌های افزونه‌ای (Redundancy)، مکانیزم‌های Failover و Load Balancing، تضمین می‌کند که سرویس‌ها همواره در دسترس باشند و از قطعی‌های ناگهانی جلوگیری شود.

---

۱. جلوگیری از Downtime و افزایش قابلیت اطمینان سیستم‌ها

Downtime یا زمان خرابی به دوره‌ای اشاره دارد که یک سرویس، اپلیکیشن یا سرور قادر به ارائه خدمات نیست. HA با فراهم کردن مکانیزم‌های بازیابی خودکار (Automatic Recovery) و سرورهای پشتیبان (Backup Servers)، از بروز خرابی‌های طولانی جلوگیری می‌کند.

مثال: راه‌اندازی Failover برای یک سرویس حیاتی در لینوکس

استفاده از Keepalived برای ایجاد یک سیستم Failover:

نصب Keepalived:

sudo apt install keepalived -y

پیکربندی Keepalived برای ایجاد Failover بین دو سرور:

مسیر فایل: /etc/keepalived/keepalived.conf

sudo nano /etc/keepalived/keepalived.conf

افزودن تنظیمات برای Primary Server:

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass securepassword
    }
    virtual_ipaddress {
        192.168.1.100
    }
}

افزودن تنظیمات برای Backup Server (تغییر state به BACKUP و priority به مقدار کمتر):

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass securepassword
    }
    virtual_ipaddress {
        192.168.1.100
    }
}

اجرای Keepalived و بررسی عملکرد:

sudo systemctl restart keepalived
sudo systemctl enable keepalived

---

۲. تضمین عملکرد بدون وقفه در اپلیکیشن‌ها و سرویس‌های حیاتی

بسیاری از کسب‌وکارها و سازمان‌ها برای انجام فعالیت‌های خود به اپلیکیشن‌های حیاتی (Critical Applications) وابسته هستند. HA کمک می‌کند تا این سرویس‌ها بدون وقفه اجرا شوند.

مثال: استفاده از Load Balancing برای توزیع درخواست‌ها و جلوگیری از Overload شدن سرورها

نصب Nginx و پیکربندی Load Balancer:

sudo apt install nginx -y

ویرایش فایل تنظیمات Nginx:

مسیر فایل: /etc/nginx/nginx.conf

sudo nano /etc/nginx/nginx.conf

افزودن تنظیمات Load Balancing:

http {
    upstream backend_servers {
        server 192.168.1.101;
        server 192.168.1.102;
        server 192.168.1.103;
    }

    server {
        listen 80;
        location / {
            proxy_pass http://backend_servers;
        }
    }
}

اعمال تغییرات و راه‌اندازی مجدد Nginx:

sudo systemctl restart nginx

---

۳. جلوگیری از از دست رفتن داده‌ها و افزایش امنیت اطلاعات

از دست رفتن داده‌ها می‌تواند خسارت‌های جبران‌ناپذیری ایجاد کند. HA با استفاده از روش‌هایی مانند Replication و Backupهای زمان‌بندی‌شده، امنیت داده‌ها را تضمین می‌کند.

مثال: پیکربندی MySQL Replication برای جلوگیری از از دست رفتن اطلاعات

فعال‌سازی Master-Slave Replication در MySQL:

ویرایش تنظیمات سرور Master:

مسیر فایل: /etc/mysql/mysql.conf.d/mysqld.cnf

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

افزودن تنظیمات زیر:

server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = mydatabase

اجرای MySQL و ایجاد کاربر Replica:

mysql -u root -p

CREATE USER 'replica'@'%' IDENTIFIED BY 'replica_password';
GRANT REPLICATION SLAVE ON *.* TO 'replica'@'%';
FLUSH PRIVILEGES;
SHOW MASTER STATUS;

ویرایش تنظیمات سرور Slave:

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

server-id = 2
relay_log = /var/log/mysql/mysql-relay-bin.log

اتصال سرور Slave به Master:

CHANGE MASTER TO 
MASTER_HOST='192.168.1.101', 
MASTER_USER='replica', 
MASTER_PASSWORD='replica_password', 
MASTER_LOG_FILE='mysql-bin.000001', 
MASTER_LOG_POS=  154;
START SLAVE;

بررسی وضعیت Replication:

SHOW SLAVE STATUS\G;

---

۴. بهبود تجربه کاربری و افزایش رضایت مشتریان

کاهش زمان بارگذاری (Latency) و افزایش دسترس‌پذیری سرویس‌ها باعث بهبود تجربه کاربران و افزایش اعتماد مشتریان می‌شود.

مثال: استفاده از CDN برای توزیع محتوا و بهبود سرعت دسترسی کاربران

افزودن Cloudflare یا یک CDN محلی برای توزیع بار:

curl -X POST "https://api.cloudflare.com/client/v4/zones/YOUR_ZONE_ID/purge_cache" \
     -H "X-Auth-Email: YOUR_EMAIL" \
     -H "X-Auth-Key: YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     --data '{"purge_everything":true}'

---

جمع‌بندی

HA (High Availability) تضمین می‌کند که سرویس‌ها و اپلیکیشن‌ها همیشه در دسترس باشند و از قطعی‌های ناگهانی، از دست رفتن داده‌ها و نارضایتی کاربران جلوگیری شود. برخی از مهم‌ترین راهکارهای HA شامل Failover، Load Balancing، Replication و Backup است که در مثال‌های عملی بررسی شد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تأثیرات منفی قطعی سرویس‌ها بر روی کسب‌وکار” subtitle=”توضیحات کامل”]قطعی سرویس‌ها یکی از مهم‌ترین چالش‌ها برای هر کسب‌وکار دیجیتالی است. حتی یک اختلال کوتاه‌مدت می‌تواند منجر به از دست رفتن درآمد، کاهش بهره‌وری، نارضایتی مشتریان و آسیب به اعتبار برند شود. در ادامه، مهم‌ترین پیامدهای منفی Downtime را بررسی می‌کنیم.

---

۱. از دست رفتن درآمد و ضرر مالی مستقیم

وقتی یک وب‌سایت فروشگاهی، سرویس آنلاین یا اپلیکیشن بانکی از دسترس خارج شود، کاربران نمی‌توانند خرید کنند، تراکنش انجام دهند یا از خدمات استفاده کنند. این امر منجر به کاهش فروش و درآمد می‌شود.

مثال واقعی:

• آمازون در سال ۲۰۱۸ به دلیل یک قطعی ۶۳ دقیقه‌ای در روز Prime Day، حدود ۹۹ میلیون دلار ضرر کرد.
• نتفلیکس در یک اختلال چندساعته، هزاران کاربر را از دست داد و باعث نارضایتی مشتریان شد.

راهکار: استفاده از Load Balancing و سیستم‌های HA برای اطمینان از پایداری سرویس‌ها.

پیکربندی Load Balancing با Nginx برای توزیع درخواست‌ها:

مسیر فایل: /etc/nginx/nginx.conf

sudo nano /etc/nginx/nginx.conf

افزودن سرورهای پشتیبان:

http {
    upstream backend_servers {
        server 192.168.1.101;
        server 192.168.1.102;
    }

    server {
        listen 80;
        location / {
            proxy_pass http://backend_servers;
        }
    }
}

اعمال تغییرات و راه‌اندازی مجدد Nginx:

sudo systemctl restart nginx

---

۲. نارضایتی مشتریان و کاهش اعتماد کاربران

قطعی‌های مداوم باعث بی‌اعتمادی کاربران می‌شود. مشتریانی که چندین بار با سرویس غیرقابل‌دسترسی مواجه شوند، احتمالاً به رقبای شما روی می‌آورند.

مثال:

• بانک‌ها و شرکت‌های پرداخت آنلاین اگر دچار Downtime شوند، مشتریان ممکن است به مؤسسات دیگر اعتماد کنند.
• وب‌سایت‌های خبری و رسانه‌ها هنگام قطعی، ترافیک خود را از دست می‌دهند و کاربران به رقبا مراجعه می‌کنند.

راهکار: پیاده‌سازی Failover و مانیتورینگ سرویس‌ها برای تشخیص مشکلات و رفع سریع آن‌ها.

راه‌اندازی Keepalived برای Failover بین دو سرور:

مسیر فایل: /etc/keepalived/keepalived.conf

sudo nano /etc/keepalived/keepalived.conf

افزودن تنظیمات برای سرور اصلی:

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    virtual_ipaddress {
        192.168.1.100
    }
}

افزودن تنظیمات برای سرور پشتیبان:

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 90
    virtual_ipaddress {
        192.168.1.100
    }
}

---

۳. کاهش بهره‌وری کارکنان و اختلال در عملیات داخلی

اگر سیستم‌های داخلی شرکت دچار قطعی شوند، کارکنان نمی‌توانند وظایف خود را انجام دهند و روند کاری مختل می‌شود.

مثال:

• اگر سیستم مدیریت ارتباط با مشتری (CRM) یک شرکت از کار بیفتد، تیم فروش نمی‌تواند با مشتریان ارتباط برقرار کند.
• قطعی سیستم‌های اتوماسیون و ERP باعث کاهش سرعت پردازش سفارشات و پشتیبانی می‌شود.

راهکار: استفاده از سرورهای پشتیبان و پایگاه‌های داده Replication برای جلوگیری از از دست رفتن اطلاعات.

پیکربندی MySQL Replication برای حفظ داده‌ها:

ویرایش تنظیمات سرور Master:

مسیر فایل: /etc/mysql/mysql.conf.d/mysqld.cnf

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

افزودن تنظیمات زیر:

server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = mydatabase

ایجاد کاربر Replica در MySQL:

CREATE USER 'replica'@'%' IDENTIFIED BY 'replica_password';
GRANT REPLICATION SLAVE ON *.* TO 'replica'@'%';
FLUSH PRIVILEGES;
SHOW MASTER STATUS;

اتصال سرور Slave به Master:

CHANGE MASTER TO 
MASTER_HOST='192.168.1.101', 
MASTER_USER='replica', 
MASTER_PASSWORD='replica_password', 
MASTER_LOG_FILE='mysql-bin.000001', 
MASTER_LOG_POS= 154;
START SLAVE;

بررسی وضعیت Replication:

SHOW SLAVE STATUS\G;

---

۴. آسیب به اعتبار برند و مشکلات قانونی

سرویس‌هایی که دچار قطعی‌های مکرر می‌شوند، اعتبار خود را از دست می‌دهند. برخی صنایع مانند بانکداری، مراقبت‌های بهداشتی و تجارت الکترونیک تحت مقررات سخت‌گیرانه قرار دارند و Downtime می‌تواند جرایم و مجازات‌های قانونی به همراه داشته باشد.

مثال:

• GDPR و HIPAA در اتحادیه اروپا و آمریکا، شرکت‌هایی را که داده‌های مشتریان را در معرض خطر قرار دهند، جریمه می‌کنند.
• سازمان‌های مالی ملزم به حداقل زمان در دسترس بودن هستند، و Downtime ممکن است جرایم سنگین مالی داشته باشد.

راهکار: استفاده از مانیتورینگ ۲۴/۷ و Disaster Recovery Plan برای جلوگیری از آسیب‌های قانونی.

مانیتورینگ سرورها با Zabbix:

sudo apt install zabbix-agent -y
sudo systemctl start zabbix-agent
sudo systemctl enable zabbix-agent

---

جمع‌بندی

Downtime یا قطعی سرویس‌ها می‌تواند تأثیرات مخربی بر روی کسب‌وکارها داشته باشد، از جمله کاهش درآمد، نارضایتی مشتریان، کاهش بهره‌وری کارکنان و آسیب به اعتبار برند. راهکارهای HA (High Availability) مانند Failover، Load Balancing، Replication و مانیتورینگ می‌توانند از این مشکلات جلوگیری کنند و پایداری سرویس‌ها را تضمین نمایند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 3. تفاوت بین High Availability و Fault Tolerance”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”توضیح مفهومی و تکنیکی تفاوت‌ها” subtitle=”توضیحات کامل”]در دنیای فناوری اطلاعات، مفاهیم High Availability (HA) و Fault Tolerance (FT) به صورت گسترده‌ای برای افزایش پایداری و دسترسی به سیستم‌ها مورد استفاده قرار می‌گیرند. این دو مفهوم ممکن است مشابه به نظر برسند، اما تفاوت‌های کلیدی دارند که در زیر به تفصیل بررسی می‌کنیم.

---

۱. High Availability (HA) چیست؟

High Availability به معنای دستیابی مستمر و پایدار به سرویس‌ها و سیستم‌ها با حداقل زمان خرابی است. هدف اصلی HA این است که در صورت وقوع یک مشکل یا خرابی، سیستم به سرعت بازیابی شده و دسترسی به سرویس‌ها برقرار باشد. HA به طور عمده بر روی کاهش زمان قطعی (Downtime) تمرکز دارد.

• ویژگی‌ها و هدف HA:
  • هدف: کاهش Downtime تا حد ممکن.
  • نحوه عملکرد: با استفاده از سیستم‌های پشتیبان (Backup Systems) و Load Balancers، زمانی که یک سرور از دسترس خارج می‌شود، سیستم به طور خودکار درخواست‌ها را به سرورهای پشتیبان هدایت می‌کند.
  • مثال: یک وب‌سایت با استفاده از چند سرور برای پشتیبانی از ترافیک می‌تواند در صورت خرابی یک سرور، همچنان بدون قطعی به سرویس‌دهی ادامه دهد.

پیکربندی HA با استفاده از Nginx Load Balancer

مسیر فایل: /etc/nginx/nginx.conf

sudo nano /etc/nginx/nginx.conf

افزودن پیکربندی برای Load Balancer:

http {
    upstream backend_servers {
        server 192.168.1.101;
        server 192.168.1.102;
    }

    server {
        listen 80;
        location / {
            proxy_pass http://backend_servers;
        }
    }
}

اعمال تغییرات و راه‌اندازی مجدد Nginx:

sudo systemctl restart nginx

---

۲. Fault Tolerance چیست؟

Fault Tolerance به معنای توانایی سیستم برای ادامه کار به صورت درست و بدون اختلال، حتی در صورت وقوع خطا یا خرابی در یکی از اجزای آن است. در این سیستم‌ها، در صورت بروز مشکل در یک قطعه سخت‌افزاری یا نرم‌افزاری، سیستم به طور کامل از کار نمی‌افتد و بدون تأثیر بر عملکرد، به کار خود ادامه می‌دهد.

• ویژگی‌ها و هدف Fault Tolerance:
  • هدف: حفظ عملکرد سیستم حتی در صورت وقوع خرابی.
  • نحوه عملکرد: در Fault Tolerant سیستم‌ها، معمولا از اجزای اضافی (Redundant Components) و مکانیزم‌های خودکار برای شناسایی خرابی‌ها استفاده می‌شود. این سیستم‌ها به گونه‌ای طراحی شده‌اند که بدون وقفه و به صورت خودکار خرابی‌ها را جبران می‌کنند.
  • مثال: یک سرور با دیسک‌های RAID که در صورت خرابی یکی از دیسک‌ها، بدون اختلال در عملکرد سیستم، داده‌ها را از دیسک دیگر بازیابی می‌کند.

پیکربندی Fault Tolerance با استفاده از RAID (Redundant Array of Independent Disks):

مسیر فایل: /etc/mdadm/mdadm.conf

sudo nano /etc/mdadm/mdadm.conf

پیکربندی RAID 1 برای Mirror کردن داده‌ها:

DEVICE /dev/sda /dev/sdb
ARRAY /dev/md0 level=1 num-devices=2 UUID=<UUID> devices=/dev/sda,/dev/sdb

اعمال تنظیمات RAID:

sudo mdadm --create /dev/md0 --assume-clean --level=1 --raid-devices=2 /dev/sda /dev/sdb

---

۳. تفاوت‌های کلیدی بین HA و Fault Tolerance

• هدف اصلی:
  • HA به دنبال کاهش زمان خرابی و اطمینان از دسترسی مداوم به سیستم‌ها است، در حالی که FT به دنبال حفظ عملکرد سیستم حتی در صورت وقوع خرابی است.
• نحوه مقابله با خرابی‌ها:
  • در HA، اگر یک سیستم یا سرور از کار بیفتد، سیستم از طریق پشتیبان‌ها یا سرورهای دیگر ادامه می‌دهد، اما ممکن است هنوز اختلالات کوتاه‌مدت وجود داشته باشد.
  • در FT، سیستم به گونه‌ای طراحی شده است که حتی در صورت خرابی یکی از اجزا، هیچ گونه اختلالی در عملکرد وجود نخواهد داشت.
• پیچیدگی و هزینه:
  • Fault Tolerance به دلیل نیاز به اجزای اضافی و سخت‌افزار خاص مانند دیسک‌های RAID یا ماشین‌های اضافی، به طور معمول هزینه بیشتری دارد.
  • HA معمولاً نیاز به پیکربندی نرم‌افزاری و توزیع ترافیک بین سرورها دارد و می‌تواند به روشی ساده‌تر پیاده‌سازی شود.
• مقایسه در سناریوهای عملی:
  • در HA، یک Load Balancer برای توزیع بار بین چندین سرور استفاده می‌شود، اما ممکن است زمانی که همه سرورها به یکباره از دسترس خارج شوند، سیستم از کار بیفتد.
  • در FT، اگر هر یک از اجزای سیستم خراب شود، سیستم بدون هیچ تأثیری به کار خود ادامه می‌دهد.

---

جمع‌بندی

High Availability و Fault Tolerance دو رویکرد مختلف برای افزایش پایداری و عملکرد سیستم‌ها هستند. در حالی که HA بر کاهش زمان خرابی و دستیابی به سرویس‌های مداوم تمرکز دارد، FT بیشتر بر حفظ عملکرد سیستم بدون هیچ گونه اختلالی در صورت خرابی اجزای سیستم است. هر دو رویکرد برای پایداری و کارایی سیستم‌ها ضروری هستند، اما بسته به نیازهای کسب‌وکار و هزینه‌های پیاده‌سازی می‌توان از یکی از این دو روش استفاده کرد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تفاوت در نحوه پاسخ به خرابی‌ها و زمان بازیابی” subtitle=”توضیحات کامل”]در دنیای فناوری اطلاعات، پاسخ به خرابی‌ها و زمان بازیابی از عوامل حیاتی برای پایداری سیستم‌ها هستند. در این بخش به تفاوت‌های اصلی بین High Availability (HA) و Fault Tolerance (FT) در نحوه پاسخ به خرابی‌ها و زمان بازیابی پرداخته می‌شود.

---

۱. نحوه پاسخ به خرابی‌ها در High Availability (HA)

در سیستم‌های High Availability (HA)، هدف اصلی کاهش زمان خرابی و حفظ دسترسی به سرویس‌ها حتی در صورت بروز خرابی است. اما زمان بازیابی پس از خرابی ممکن است به مدت زمانی نیاز داشته باشد تا سیستم به حالت عادی بازگردد. این زمان بازیابی بستگی به نوع پیکربندی و تعداد سرورهای پشتیبان دارد.

• پاسخ به خرابی‌ها:
  • در HA، زمانی که یک سرویس یا سرور دچار خرابی می‌شود، از سرورهای پشتیبان یا مکانیزم‌های خودکار مانند Load Balancer برای هدایت ترافیک به سرورهای سالم استفاده می‌شود.
  • خرابی ممکن است در ابتدا موجب قطعی موقت شود، اما با استفاده از سیستم‌های پشتیبان، سرویس به سرعت باز می‌گردد.
  • این سیستم‌ها به گونه‌ای طراحی شده‌اند که اگر یک سرور خراب شود، ترافیک به سرورهای دیگر هدایت شود، اما بازیابی کامل ممکن است چند ثانیه یا دقیقه به طول انجامد.
• زمان بازیابی:
  • زمان بازیابی در HA بستگی به پیکربندی سیستم و نوع خرابی دارد. در برخی موارد، بازیابی می‌تواند بلافاصله انجام شود، در حالی که در موارد پیچیده‌تر ممکن است زمان بیشتری نیاز باشد.
  • Load Balancer معمولاً در چند ثانیه ترافیک را به سرورهای سالم هدایت می‌کند، اما در مواردی که نیاز به جایگزینی سرور معیوب باشد، زمان بیشتری لازم است.

پیکربندی HA برای Load Balancer و زمان بازیابی:

مسیر فایل: /etc/nginx/nginx.conf

sudo nano /etc/nginx/nginx.conf

پیکربندی Load Balancer برای HA:

upstream backend_servers {
    server 192.168.1.101;
    server 192.168.1.102;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend_servers;
    }
}

اعمال تنظیمات و راه‌اندازی مجدد Nginx:

sudo systemctl restart nginx

در این پیکربندی، اگر یکی از سرورها خراب شود، Load Balancer به سرعت ترافیک را به سرور سالم هدایت می‌کند و زمان بازیابی در حد چند ثانیه خواهد بود.

---

۲. نحوه پاسخ به خرابی‌ها در Fault Tolerance (FT)

در Fault Tolerance (FT)، پاسخ به خرابی‌ها به گونه‌ای است که سیستم بدون هیچ گونه اختلالی به کار خود ادامه می‌دهد، حتی اگر یکی از اجزای سیستم دچار مشکل شود. در این سیستم‌ها، خرابی یک قطعه از سیستم به هیچ عنوان بر عملکرد کلی سیستم تأثیر نمی‌گذارد. این بدان معناست که زمانی که خطایی در سیستم رخ می‌دهد، سیستم به صورت خودکار و بدون هیچ وقفه‌ای از طریق اجزای اضافی مشکل را جبران می‌کند.

• پاسخ به خرابی‌ها:
  • در FT، اگر یک قطعه مانند دیسک سخت‌افزاری، سرور یا کارت شبکه خراب شود، سیستم به طور خودکار از اجزای redundant (اضافی) استفاده می‌کند.
  • هیچ اختلالی در عملکرد کلی سیستم رخ نمی‌دهد، زیرا سیستم به گونه‌ای طراحی شده است که از عملکرد اضافی و جانشین برای تمام اجزا استفاده می‌کند.
  • در صورتی که یکی از اجزا خراب شود، سیستم با استفاده از تکنیک‌های failover، به مدل پشتیبانی خودکار (fail-safe) تغییر وضعیت می‌دهد.
• زمان بازیابی:
  • در Fault Tolerance, هیچ زمان بازیابی خاصی نیاز نیست، زیرا سیستم به طور مستمر بدون وقفه کار می‌کند و هیچگونه خرابی محسوس برای کاربر وجود ندارد.
  • عملکرد سیستم به طور خودکار از طریق اجزای redundant در صورت خرابی ادامه می‌یابد و نیاز به زمان بازیابی ندارد.

پیکربندی Fault Tolerance با استفاده از RAID 1 برای حفاظت از داده‌ها:

مسیر فایل: /etc/mdadm/mdadm.conf

sudo nano /etc/mdadm/mdadm.conf

پیکربندی RAID 1 برای Redundancy داده‌ها:

DEVICE /dev/sda /dev/sdb
ARRAY /dev/md0 level=1 num-devices=2 UUID=<UUID> devices=/dev/sda,/dev/sdb

اعمال تنظیمات و راه‌اندازی RAID:

sudo mdadm --create /dev/md0 --assume-clean --level=1 --raid-devices=2 /dev/sda /dev/sdb

در این پیکربندی، در صورت خرابی یکی از دیسک‌ها، داده‌ها به صورت خودکار از دیسک دیگر بازیابی می‌شود و زمان بازیابی وجود ندارد.

---

۳. مقایسه زمان بازیابی در HA و FT

• High Availability:
  زمان بازیابی در HA معمولاً چند ثانیه تا چند دقیقه به طول می‌انجامد. این زمان بستگی به نوع خرابی و پیکربندی سیستم دارد. ممکن است زمانی که سرور اصلی از دسترس خارج شود، Load Balancer به سرعت ترافیک را به سرورهای دیگر هدایت کند و زمان بازیابی به حداقل برسد.
• Fault Tolerance:
  در FT، زمان بازیابی وجود ندارد زیرا سیستم به طور پیوسته و بدون وقفه از اجزای اضافی برای ادامه عملکرد استفاده می‌کند. در صورتی که یکی از اجزا خراب شود، سیستم به صورت خودکار از اجزای اضافی استفاده می‌کند و هیچ اختلالی در عملکرد ایجاد نمی‌شود.

---

جمع‌بندی

High Availability و Fault Tolerance در پاسخ به خرابی‌ها و زمان بازیابی تفاوت‌های قابل توجهی دارند. در HA، زمانی که یک بخش از سیستم خراب می‌شود، بازیابی ممکن است چند ثانیه یا دقیقه طول بکشد، در حالی که در FT، سیستم به طور پیوسته از اجزای اضافی برای ادامه کار استفاده می‌کند و هیچ زمان بازیابی وجود ندارد. Fault Tolerance معمولاً برای سیستم‌هایی با نیاز به عملکرد بدون وقفه و سیستم‌های بحرانی استفاده می‌شود، در حالی که High Availability بیشتر در مواردی استفاده می‌شود که هدف کاهش زمان خرابی است.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”استفاده از HA در مقایسه با Fault Tolerance در محیط‌های مختلف” subtitle=”توضیحات کامل”]در دنیای فناوری اطلاعات، انتخاب بین High Availability (HA) و Fault Tolerance (FT) بستگی به نیازهای خاص محیط‌ها و سیستم‌ها دارد. این دو رویکرد برای حفظ پایداری سیستم‌ها طراحی شده‌اند، اما بسته به نوع سیستم و هدف‌های سازمان، ممکن است یکی از آنها ترجیح داده شود. در این بخش، تفاوت‌های استفاده از HA و FT در محیط‌های مختلف مورد بررسی قرار می‌گیرد.

---

۱. استفاده از High Availability (HA) در محیط‌های مختلف

High Availability (HA) به معنای فراهم کردن دسترس‌پذیری بالا و کاهش زمان خرابی در هنگام خرابی اجزای سیستم است. این رویکرد معمولاً برای سیستم‌های غیر بحرانی که نیاز به دسترسی مداوم دارند اما پیوستگی کامل برای عملکرد لازم نیست، مناسب است.

• محیط‌های تجاری کوچک و متوسط:
  • در این محیط‌ها، سازمان‌ها ممکن است به دسترس‌پذیری بالا نیاز داشته باشند، اما هزینه پیاده‌سازی Fault Tolerance که نیاز به تجهیزات و پیکربندی‌های پیچیده دارد، ممکن است بسیار بالا باشد. در این موارد، HA گزینه‌ای مقرون به صرفه‌تر است.
  • مثال عملی:
    • وب‌سایت‌های تجاری کوچک که نیاز به دسترس‌پذیری بالا دارند. اگر یکی از سرورها دچار خرابی شود، ترافیک به سرورهای پشتیبان منتقل می‌شود تا قطعی‌ها کاهش یابد. Load Balancer معمولاً برای این هدف به کار می‌رود.
• محیط‌های Cloud Computing (پردازش ابری):
  • در محیط‌های ابری، HA برای مقیاس‌پذیری سریع و مقاطع زمانی کم‌توقف ایده‌آل است. بسیاری از ارائه‌دهندگان cloud services به‌طور پیش‌فرض پشتیبانی از HA را در لایه‌های مختلف (از جمله ذخیره‌سازی و محاسبات) فراهم می‌آورند.
  • مثال عملی:
    • Amazon Web Services (AWS) از Elastic Load Balancer و Auto Scaling برای مدیریت بار و افزایش دسترس‌پذیری بالا استفاده می‌کند.

پیکربندی HA در AWS:

مسیر فایل: /etc/nginx/nginx.conf

sudo nano /etc/nginx/nginx.conf

پیکربندی Load Balancer در AWS:

upstream backend_servers {
    server 192.168.1.101;
    server 192.168.1.102;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend_servers;
    }
}

اعمال تنظیمات و راه‌اندازی مجدد Nginx:

sudo systemctl restart nginx

---

۲. استفاده از Fault Tolerance (FT) در محیط‌های مختلف

Fault Tolerance (FT) به معنای طراحی سیستم‌ها به گونه‌ای است که بدون هیچ وقفه‌ای در عملکرد خود به ادامه کار بپردازند، حتی اگر اجزای مختلف سیستم خراب شوند. این رویکرد برای سیستم‌هایی که نیاز به عملکرد بدون توقف دارند، ضروری است.

• محیط‌های بحرانی و مهم (Critical Systems):
  • در محیط‌هایی که هیچ قطعی نباید رخ دهد و زمان بازیابی صفر اهمیت دارد، استفاده از Fault Tolerance ضروری است. این محیط‌ها معمولاً به در دسترس بودن دائم و پیوستگی عملیات نیاز دارند.
  • مثال عملی:
    • سیستم‌های بانکی: که نیاز به عملکرد مستمر دارند. حتی اگر یک سرور یا دیسک خراب شود، باید از طریق سیستم‌های redundant و backup به طور خودکار عملیات ادامه یابد.
• محیط‌های پردازش داده‌های حیاتی (Mission-Critical Environments):
  • برای محیط‌هایی که به پردازش داده‌های حساس و پیوسته نیاز دارند، مانند سیستم‌های پزشکی یا نظارتی، باید از Fault Tolerance استفاده شود تا سیستم حتی در صورت خرابی یکی از اجزای اصلی، بدون وقفه به فعالیت خود ادامه دهد.
  • مثال عملی:
    • سیستم‌های نظارتی شبکه‌ها که نیاز دارند بدون توقف داده‌ها را پردازش کنند. در این سیستم‌ها از RAID 1 یا RAID 5 برای حفاظت از داده‌ها استفاده می‌شود.

پیکربندی Fault Tolerance با RAID 1:

مسیر فایل: /etc/mdadm/mdadm.conf

sudo nano /etc/mdadm/mdadm.conf

پیکربندی RAID 1 برای Redundancy داده‌ها:

DEVICE /dev/sda /dev/sdb
ARRAY /dev/md0 level=1 num-devices=2 UUID=<UUID> devices=/dev/sda,/dev/sdb

اعمال تنظیمات و راه‌اندازی RAID:

sudo mdadm --create /dev/md0 --assume-clean --level=1 --raid-devices=2 /dev/sda /dev/sdb

---

۳. مقایسه استفاده از HA و FT در محیط‌های مختلف

• High Availability (HA):
  • بیشتر در محیط‌های تجاری و پردازش ابری که زمان خرابی باید به حداقل برسد، استفاده می‌شود.
  • مناسب برای سیستم‌های غیر بحرانی که به دسترس‌پذیری بالا نیاز دارند، اما از نظر عملکرد پیوسته الزاماتی ندارند.
• Fault Tolerance (FT):
  • مناسب برای سیستم‌های بحرانی و پیشرفته که هیچ گونه خرابی یا اختلالی را تحمل نمی‌کنند.
  • بهترین گزینه برای سیستم‌های نظارتی، پزشکی و مالی که به عملکرد بدون توقف نیاز دارند.

---

جمع‌بندی

در محیط‌های مختلف، انتخاب بین High Availability و Fault Tolerance به نیازهای خاص سیستم بستگی دارد. HA معمولاً برای سیستم‌های تجاری و ابری که نیاز به دسترس‌پذیری بالا دارند، استفاده می‌شود، در حالی که FT برای سیستم‌های بحرانی که به عملکرد مستمر و بدون وقفه نیاز دارند، انتخاب بهتری است.[/cdb_course_lesson][cdb_course_lesson title=”فصل 4. مفاهیم کلیدی در High Availability”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مفهوم Failover: فرآیند جابجایی به منابع پشتیبان در صورت بروز مشکل” subtitle=”توضیحات کامل”]Failover به فرآیند انتقال خودکار یا جابجایی به منابع پشتیبان در صورت بروز مشکلات و خرابی‌ها در یک سیستم یا زیرساخت اطلاق می‌شود. این فرآیند از دسترس‌پذیری بالا (HA) و پایداری سیستم‌ها پشتیبانی می‌کند و اطمینان حاصل می‌کند که سیستم‌ها و سرویس‌ها حتی در صورت بروز خرابی یا قطعی، به کار خود ادامه می‌دهند.

هدف اصلی Failover این است که خدمات و منابع بدون وقفه در دسترس باشند و تأثیر خرابی‌ها بر عملکرد سیستم به حداقل برسد. این ویژگی در بسیاری از سیستم‌های بحرانی و تجاری مانند سرورهای وب، دیتابیس‌ها، شبکه‌ها، و برنامه‌های کاربردی حیاتی است.

---

فرآیند Failover

فرآیند Failover معمولاً در چند مرحله انجام می‌شود:

1. تشخیص خرابی:
   • اولین مرحله در Failover، شناسایی و تشخیص خرابی است. این شامل تشخیص مشکلاتی مانند خرابی سخت‌افزار، از دست رفتن اتصال به شبکه یا خطاهای نرم‌افزاری است.
2. انتقال به منبع پشتیبان:
   • پس از تشخیص خرابی، سیستم به طور خودکار یا دستی به یک منبع پشتیبان یا سرور جایگزین منتقل می‌شود. این منابع پشتیبان معمولاً در یک مکان جغرافیایی متفاوت یا در سیستم‌های مشابه قرار دارند.
3. بازگردانی وضعیت:
   • پس از انجام انتقال Failover، سیستم باید وضعیت و اطلاعات از دست رفته را بازیابی کند تا سرویس‌ها به حالت عادی بازگردند. این فرآیند می‌تواند شامل همگام‌سازی داده‌ها و نقل و انتقال اطلاعات باشد.
4. بازگشت به وضعیت عادی (Failback):
   • زمانی که منبع اصلی به طور کامل بازسازی یا عملکرد صحیح خود را بازیابی کند، ممکن است سیستم به وضعیت اولیه بازگردد. این فرآیند را Failback می‌نامند.

---

انواع Failover

• Failover خودکار (Automatic Failover):
  در این حالت، سیستم به طور خودکار تشخیص خرابی را انجام داده و بلافاصله به منابع پشتیبان منتقل می‌شود. این فرآیند به دسترس‌پذیری بالای سیستم‌ها کمک می‌کند.
• Failover دستی (Manual Failover):
  در این حالت، فرآیند انتقال به منابع پشتیبان به صورت دستی توسط مدیر سیستم یا تیم IT انجام می‌شود. این رویکرد معمولاً در مواردی استفاده می‌شود که خودکار بودن فرآیند ممکن است نیاز به تأیید داشته باشد.

---

پیکربندی Failover در یک محیط سیستم

در اینجا نحوه پیکربندی Failover برای یک سیستم ساده با استفاده از Nginx به عنوان Load Balancer و پشتیبان توضیح داده می‌شود.

مسیر فایل: /etc/nginx/nginx.conf

1. پیکربندی Load Balancer در Nginx برای Failover:

sudo nano /etc/nginx/nginx.conf

در این پیکربندی، دو سرور پشتیبان به عنوان منابع اصلی و پشتیبان برای انجام Failover در نظر گرفته شده‌اند:

http {
    upstream backend_servers {
        server 192.168.1.100; # سرور اصلی
        server 192.168.1.101 backup; # سرور پشتیبان
    }

    server {
        listen 80;
        location / {
            proxy_pass http://backend_servers;
        }
    }
}

در این تنظیمات، وقتی سرور اصلی (192.168.1.100) دچار مشکل شود، ترافیک به طور خودکار به سرور پشتیبان (192.168.1.101) منتقل می‌شود.

2. راه‌اندازی مجدد Nginx:

sudo systemctl restart nginx

---

مزایای Failover

• کاهش زمان قطعی:
  Failover به کاهش زمان خرابی کمک می‌کند و سیستم را حتی در صورت وقوع خرابی به‌طور سریع به وضعیت عملیاتی باز می‌گرداند.
• افزایش پایداری:
  با استفاده از منابع پشتیبان و سیستم‌های اضافی, پایداری سیستم‌ها تضمین می‌شود.
• محدود کردن تأثیر خرابی‌ها:
  خرابی در یک جزء از سیستم نمی‌تواند به طور کامل بر عملکرد سیستم تأثیر بگذارد. Failover این مشکل را حل می‌کند.

---

جمع‌بندی

Failover یک ویژگی حیاتی برای اطمینان از دسترس‌پذیری بالا و پایداری در سیستم‌های پیچیده است. این فرآیند اطمینان می‌دهد که حتی در صورت خرابی، سیستم‌ها به منابع پشتیبان منتقل می‌شوند تا دسترسی به سرویس‌ها حفظ شود. پیکربندی Failover خودکار و دستی می‌تواند به سازمان‌ها کمک کند تا سیستم‌های خود را در برابر خرابی‌ها مقاوم‌تر سازند و در مواقع بحرانی، خدمات خود را به صورت مداوم ارائه دهند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مفهوم Redundancy: ایجاد نسخه‌های اضافی از منابع برای اطمینان از دسترسی” subtitle=”توضیحات کامل”]Redundancy به معنی ایجاد نسخه‌های اضافی یا پشتیبانی از منابع در یک سیستم است تا اطمینان حاصل شود که در صورت بروز خرابی یا مشکلات سخت‌افزاری یا نرم‌افزاری، دسترسی به منابع همچنان برقرار باقی بماند. این مفهوم به طور گسترده در محیط‌های High Availability (HA) و Fault Tolerance برای افزایش پایداری و کاهش زمان خرابی به کار می‌رود.

در واقع، Redundancy به معنای استفاده از منابع اضافی یا تکراری است که در صورت وقوع مشکل در یکی از منابع اصلی، به طور خودکار یا دستی وارد عمل شوند تا سیستم بدون هیچ وقفه‌ای به عملکرد خود ادامه دهد. این فرآیند باعث افزایش اطمینان و در دسترس بودن سیستم‌ها می‌شود.

---

انواع Redundancy

1. Redundancy در سخت‌افزار:
   • در این نوع Redundancy, قطعات سخت‌افزاری از جمله سرورها، دیسک‌ها، و منابع شبکه به صورت اضافی در نظر گرفته می‌شوند تا در صورت خرابی یک قطعه، به طور خودکار منابع اضافی وارد عمل شوند.
   • مثال: RAID برای ذخیره‌سازی اطلاعات، که داده‌ها را بر روی چندین دیسک ذخیره می‌کند تا در صورت خرابی یک دیسک، داده‌ها از دست نروند.
2. Redundancy در نرم‌افزار:
   • در این حالت، از نسخه‌های اضافی یا پشتیبان‌های نرم‌افزاری برای اجرای سرویس‌ها و برنامه‌ها استفاده می‌شود. این نسخه‌ها می‌توانند به صورت مستقل یا همزمان از منابع یکسان یا متفاوت باشند.
   • مثال: استفاده از Load Balancers برای توزیع ترافیک میان چندین سرور برای جلوگیری از بار اضافی روی یک سرور خاص.
3. Redundancy در شبکه:
   • این نوع Redundancy مربوط به شبکه‌ها می‌شود که از مسیرهای اضافی و سوئیچ‌های پشتیبان برای تضمین ارتباط بدون وقفه استفاده می‌کند.
   • مثال: استفاده از Multiple Network Interface Cards (NICs) برای اتصال به شبکه با مسیرهای مختلف و جلوگیری از قطعی شبکه.

---

پیکربندی Redundancy در یک محیط سرور

برای پیکربندی Redundancy در یک محیط سرور، می‌توان از HAProxy به عنوان یک Load Balancer برای توزیع بار و در دسترس بودن استفاده کرد.

مسیر فایل: /etc/haproxy/haproxy.cfg

1. پیکربندی HAProxy برای Redundancy

ابتدا فایل پیکربندی HAProxy را ویرایش می‌کنیم:

sudo nano /etc/haproxy/haproxy.cfg

سپس، تنظیمات مربوط به توزیع بار و Redundancy را به این صورت اضافه می‌کنیم:

frontend http_front
   bind *:80
   default_backend http_back

backend http_back
   balance roundrobin
   server server1 192.168.1.100:80 check
   server server2 192.168.1.101:80 check backup

در این تنظیمات، سرور اصلی server1 و سرور پشتیبان server2 به صورت Redundant و با استفاده از الگوریتم Round Robin برای توزیع بار پیکربندی شده‌اند. اگر سرور اول خراب شود، ترافیک به سرور پشتیبان منتقل می‌شود.

2. راه‌اندازی مجدد HAProxy

sudo systemctl restart haproxy

---

مزایای Redundancy

• کاهش زمان خرابی:
  با استفاده از منابع پشتیبان، در صورت خرابی یک سیستم، سیستم به سرعت به حالت فعال برمی‌گردد و از قطعی‌ها جلوگیری می‌شود.
• افزایش پایداری و دسترس‌پذیری:
  منابع اضافی باعث می‌شوند که سیستم‌ها بدون هیچگونه توقفی به کار خود ادامه دهند.
• افزایش تحمل خطا:
  در صورت خرابی یکی از اجزا، منابع اضافی باعث جلوگیری از توقف کل سیستم می‌شوند و تنها بخشی از سیستم دچار مشکل می‌شود.

---

جمع‌بندی

Redundancy یک تکنیک حیاتی برای دسترس‌پذیری بالا و پایداری سیستم‌ها است. با استفاده از منابع اضافی یا پشتیبان، سیستم‌ها قادر به تحمل خرابی‌ها و جلوگیری از قطعی‌های طولانی مدت هستند. این فرآیند به کاهش زمان خرابی و افزایش قابلیت اعتماد به سیستم کمک می‌کند و در بسیاری از سیستم‌های بحرانی و تجاری از آن استفاده می‌شود.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مفهوم Replication: تکرار داده‌ها برای محافظت در برابر از دست دادن اطلاعات” subtitle=”توضیحات کامل”]Replication به فرآیند تکرار داده‌ها یا کپی کردن داده‌ها از یک منبع به یک یا چند مکان دیگر گفته می‌شود. هدف اصلی از Replication حفاظت از داده‌ها در برابر از دست دادن اطلاعات به دلیل خرابی‌های سخت‌افزاری، خطاهای نرم‌افزاری یا مشکلات شبکه است. این فرآیند به ویژه در سیستم‌های ذخیره‌سازی و پایگاه داده‌ها برای افزایش دسترس‌پذیری و پایداری استفاده می‌شود.

در واقع، Replication به این معناست که داده‌ها به صورت مستقل یا همزمان در مکان‌های مختلف نگهداری می‌شوند تا در صورت خرابی یک سیستم، نسخه‌های دیگر داده‌ها همچنان در دسترس باشند و اطلاعات از دست نروند.

---

انواع Replication

1. Synchronous Replication (تکرار همزمان):
   در این نوع، داده‌ها در همان زمان که در سرور اصلی تغییر می‌کنند، در سرورهای پشتیبان نیز به‌روزرسانی می‌شوند. این روش موجب تضمین همگام بودن داده‌ها در تمام سیستم‌ها می‌شود، اما ممکن است عملکرد سیستم را کاهش دهد.
   • مزایا:
     • داده‌ها همیشه همگام و دقیق هستند.
     • از بروز مشکلات ناشی از عدم همگامی داده‌ها جلوگیری می‌کند.
   • معایب:
     • کاهش عملکرد به دلیل زمان تأخیر در فرآیند تکرار.
     • نیاز به اتصال پایدار و با تأخیر کم بین سیستم‌ها.
2. Asynchronous Replication (تکرار غیرهمزمان):
   در این نوع، داده‌ها پس از تغییرات در سرور اصلی، به صورت دوره‌ای یا با تأخیر مشخص به سرورهای پشتیبان منتقل می‌شوند. این روش معمولاً عملکرد سریع‌تری دارد، اما ممکن است در صورت خرابی، داده‌های جدید در دسترس نباشند.
   • مزایا:
     • افزایش سرعت عملکرد سیستم.
     • بار اضافی کمتر روی سیستم.
   • معایب:
     • احتمال از دست رفتن داده‌ها در صورت بروز خرابی قبل از انتقال به سرور پشتیبان.
     • عدم همگامی کامل بین سرورها.

---

پیکربندی Replication در یک پایگاه داده MySQL

برای پیاده‌سازی Replication در MySQL، می‌توان از Replication Master-Slave استفاده کرد. در این مدل، یک سرور به عنوان Master و سایر سرورها به عنوان Slave عمل می‌کنند.

1. پیکربندی Master

ابتدا در سرور Master، فایل پیکربندی MySQL را ویرایش می‌کنیم:

sudo nano /etc/mysql/my.cnf

در فایل پیکربندی، بخش زیر را اضافه می‌کنیم:

[mysqld]
log-bin=mysql-bin
server-id=1

سپس سرویس MySQL را دوباره راه‌اندازی می‌کنیم:

sudo systemctl restart mysql

2. ایجاد کاربر Replication در Master

در سرور Master، یک کاربر برای Replication ایجاد می‌کنیم:

CREATE USER 'replication_user'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'replication_user'@'%';
FLUSH PRIVILEGES;

3. پیکربندی Slave

در سرور Slave، فایل پیکربندی MySQL را ویرایش می‌کنیم:

sudo nano /etc/mysql/my.cnf

در این فایل، بخش‌های زیر را اضافه می‌کنیم:

[mysqld]
server-id=2

سپس سرویس MySQL را دوباره راه‌اندازی می‌کنیم:

sudo systemctl restart mysql

4. اتصال به Master از سرور Slave

در سرور Slave، برای اتصال به Master و شروع فرآیند Replication، دستور زیر را اجرا می‌کنیم:

CHANGE MASTER TO
  MASTER_HOST='MASTER_IP',
  MASTER_USER='replication_user',
  MASTER_PASSWORD='password',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=  154;
START SLAVE;

پس از انجام این مراحل، Slave شروع به دریافت داده‌ها از Master می‌کند.

5. بررسی وضعیت Replication

برای بررسی وضعیت Replication در Slave، از دستور زیر استفاده می‌کنیم:

SHOW SLAVE STATUS\G

اگر همه چیز درست باشد، وضعیت Slave باید به “Yes” در ستون‌های Slave_IO_Running و Slave_SQL_Running باشد.

---

مزایای Replication

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

---

جمع‌بندی

Replication یک روش حیاتی برای محافظت از داده‌ها و افزایش دسترس‌پذیری در سیستم‌ها است. با تکرار داده‌ها در چندین سرور یا مکان، می‌توان از دست رفتن اطلاعات جلوگیری کرد و در صورت بروز خرابی، سیستم بدون وقفه به کار خود ادامه دهد. این روش در پایگاه داده‌ها، سیستم‌های ذخیره‌سازی و دیگر محیط‌های کاری حیاتی به کار می‌رود تا اطمینان حاصل شود که داده‌ها در تمام شرایط حفظ می‌شوند و سیستم عملکرد بهینه خود را حفظ می‌کند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 5. معرفی Clustering به عنوان راه‌حلی برای HA”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تعریف و توضیح مفهوم کلاسترینگ در HA” subtitle=”توضیحات کامل”]کلاسترینگ در High Availability (HA) به فرآیند استفاده از چندین سرور یا گره (Node) به‌منظور افزایش دسترس‌پذیری و پایداری سیستم‌ها اشاره دارد. در این فرآیند، چندین سرور به‌صورت گروهی یا کلاستر با هم کار می‌کنند تا در صورت خرابی یکی از سرورها، بار کاری به سرورهای دیگر منتقل شود و سرویس‌ها بدون وقفه در دسترس باقی بمانند. این روش برای به حداقل رساندن خرابی‌ها و ارائه عملکرد پایدار و مقاوم در برابر مشکلات طراحی می‌شود.

در کلاسترینگ، تمام گره‌ها یا سرورهای موجود در کلاستر قادر به اشتراک‌گذاری داده‌ها و منابع مشترک هستند. در صورت بروز مشکلی در یکی از گره‌ها، یکی از گره‌های دیگر به‌طور خودکار مسئولیت ادامه کار را به عهده می‌گیرد تا سرویس‌دهی به کاربران قطع نشود. این ویژگی یکی از ارکان اصلی High Availability است که تضمین می‌کند در شرایط بحرانی، سیستم همیشه در دسترس باشد.

---

انواع کلاسترینگ در HA

1. Active-Passive Clustering (کلاستر فعال-غیرفعال): در این مدل، یک گره به‌عنوان گره فعال در حال ارائه سرویس‌ها و انجام عملیات است، در حالی که گره‌های غیرفعال به‌عنوان پشتیبان آماده به کار می‌مانند. در صورت خرابی گره فعال، یکی از گره‌های غیرفعال به‌طور خودکار فعال شده و بار کاری را بر عهده می‌گیرد.
   • مزایا:
     • کاهش پیچیدگی در پیکربندی.
     • اطمینان از دسترس‌پذیری بالا با وجود گره‌های پشتیبان.
   • معایب:
     • مصرف منابع اضافی در گره‌های غیرفعال.
     • امکان اتلاف منابع در زمان‌های بدون خرابی.
2. Active-Active Clustering (کلاستر فعال-فعال): در این مدل، تمامی گره‌ها به‌طور همزمان فعال هستند و هر گره بخشی از بار کاری را انجام می‌دهد. در صورت خرابی یکی از گره‌ها، سایر گره‌ها به‌طور خودکار بار اضافی را به دوش می‌کشند تا سرویس‌دهی بدون وقفه ادامه یابد.
   • مزایا:
     • استفاده بهینه از تمامی گره‌ها.
     • جلوگیری از اتلاف منابع.
   • معایب:
     • پیچیدگی بیشتر در پیکربندی و مدیریت.
     • نیاز به هماهنگی دقیق بین گره‌ها برای جلوگیری از تداخل داده‌ها.

---

پیکربندی یک کلاستر HA در لینوکس با استفاده از Pacemaker و Corosync

در این مثال، یک کلاستر HA با استفاده از ابزارهای Pacemaker و Corosync برای مدیریت کلاستر و هماهنگی بین گره‌ها پیکربندی می‌شود.

1. نصب Pacemaker و Corosyncابتدا باید Pacemaker و Corosync را روی هر دو گره نصب کنیم:

   sudo apt-get install pacemaker corosync
   

2. پیکربندی Corosyncسپس باید فایل پیکربندی Corosync را ویرایش کنیم تا گره‌ها قادر به ارتباط با یکدیگر باشند. این فایل معمولاً در مسیر /etc/corosync/corosync.conf قرار دارد:

   sudo nano /etc/corosync/corosync.conf
   

   در این فایل، باید تنظیمات مربوط به نام کلاستر و آدرس‌های IP گره‌ها را مشخص کنیم.

3. شروع و راه‌اندازی Pacemakerپس از پیکربندی Corosync، باید Pacemaker را راه‌اندازی کنیم:

   sudo systemctl start pacemaker
   sudo systemctl enable pacemaker
   

4. ایجاد منابع HAبرای راه‌اندازی سرویس‌ها در کلاستر، ابتدا باید منابع مورد نیاز را تعریف کنیم. به‌عنوان مثال، برای راه‌اندازی یک سرویس HTTP، دستور زیر را وارد می‌کنیم:

   sudo pcs resource create httpd ocf:heartbeat:apache
   

   این دستور سرویس HTTP را روی کلاستر فعال می‌کند و در صورت خرابی گره، آن را به گره دیگری منتقل می‌کند.

5. تست پیکربندیبرای تست پیکربندی، می‌توانیم از دستور زیر برای مشاهده وضعیت منابع استفاده کنیم:

   sudo pcs status
   

   این دستور وضعیت کلاستر و منابع آن را نمایش می‌دهد و مشخص می‌کند که کدام گره فعال است و کدام گره‌ها در حال انتظار هستند.

---

مزایای کلاسترینگ در HA

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

---

جمع‌بندی

کلاسترینگ در High Availability فرآیندی است که با استفاده از چندین سرور یا گره برای اطمینان از عملکرد بدون وقفه و دسترس‌پذیری سیستم در هنگام خرابی‌ها طراحی شده است. این فناوری با استفاده از مدل‌های Active-Passive یا Active-Active می‌تواند به بهبود مقیاس‌پذیری، پایداری و عملکرد سیستم‌ها کمک کند. پیکربندی صحیح کلاسترینگ با استفاده از ابزارهایی مانند Pacemaker و Corosync امکان مدیریت منابع و جابجایی خودکار بین گره‌ها را فراهم می‌آورد و از بروز خرابی‌های غیرمنتظره جلوگیری می‌کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”نقش کلاسترها در فراهم کردن دسترس‌پذیری بالا” subtitle=”توضیحات کامل”]کلاسترها در محیط‌های High Availability (HA) نقش بسیار مهمی در تأمین دسترس‌پذیری بدون وقفه و پایداری سیستم‌ها دارند. استفاده از کلاسترها به‌ویژه در سیستم‌های بزرگ و حساس، که نیاز به کارکرد دائمی دارند، موجب می‌شود که در صورت بروز هرگونه خرابی یا مشکل در یکی از بخش‌ها، سیستم به‌طور خودکار به بخش‌های سالم منتقل شود و تأثیری بر عملکرد سرویس‌ها نداشته باشد. به‌طور کلی، کلاسترها برای افزایش دسترس‌پذیری بالا و جلوگیری از خرابی‌های غیرمنتظره طراحی شده‌اند.

در یک کلاستر، چندین سرور یا گره به‌طور هماهنگ عمل می‌کنند تا در صورت خرابی یا از کار افتادن یک سرور، سایر سرورها به‌طور خودکار نقش آن را ایفا کرده و سرویس‌دهی ادامه یابد. این فرآیند باعث می‌شود که زمان خرابی کاهش یابد و سیستم همیشه در دسترس باشد. کلاسترها همچنین به مدیریت بار و مقیاس‌پذیری کمک می‌کنند، زیرا می‌توانند به‌طور همزمان منابع را از چندین سرور بهره‌برداری کنند.

---

مکانیزم‌های کلاسترها برای تأمین دسترس‌پذیری بالا

1. Failover (جابجایی خودکار):
   یکی از ویژگی‌های کلیدی کلاسترها برای دسترس‌پذیری بالا، Failover است. در صورت بروز خرابی در یکی از گره‌ها یا سرورها، Failover به‌طور خودکار بار کاری را به گره سالم منتقل می‌کند و از قطعی سرویس جلوگیری می‌کند. این فرایند به‌طور بی‌وقفه ادامه می‌یابد و کاربران متوجه هیچ‌گونه اختلالی در سرویس‌ها نمی‌شوند.
   • در یک کلاستر Active-Passive، یک گره اصلی فعال است و گره‌های پشتیبان در حالت غیرفعال باقی می‌مانند. در صورت بروز مشکل، یکی از گره‌های غیرفعال به‌طور خودکار به گره فعال تبدیل می‌شود.
   • در یک کلاستر Active-Active، تمامی گره‌ها به‌طور همزمان فعال هستند و در صورت خرابی، سایر گره‌ها قادر به ادامه پردازش‌ها هستند.
2. Redundancy (اضافه‌سازی منابع):
   کلاسترها با Redundancy یا اضافه‌سازی منابع، از وقوع خرابی‌های احتمالی جلوگیری می‌کنند. در این مدل، هر سرور یا گره در کلاستر دارای منابع اضافی است، به‌طوری که اگر یکی از منابع یا سرورها از کار بیفتد، نسخه پشتیبان آن به‌طور خودکار جایگزین می‌شود و هیچ‌گونه وقفه‌ای در سرویس‌دهی ایجاد نمی‌شود.
   • به‌عنوان مثال، در یک سیستم ذخیره‌سازی، داده‌ها به‌طور همزمان در چندین سرور یا دستگاه ذخیره‌سازی نگهداری می‌شوند. در صورتی که یکی از دستگاه‌ها دچار مشکل شود، سیستم به‌طور خودکار به دستگاه سالم دیگر منتقل می‌شود.
3. Load Balancing (توزیع بار):
   کلاسترها به‌طور مؤثر از Load Balancing برای مدیریت بار و افزایش عملکرد استفاده می‌کنند. توزیع بار به این معناست که درخواست‌ها و کارهای مختلف به‌طور متوازن بین گره‌های مختلف کلاستر توزیع می‌شوند. این کار باعث می‌شود که هیچ گره‌ای تحت فشار زیاد قرار نگیرد و کارایی کلی سیستم افزایش یابد.
   • در کلاسترهای Active-Active، توزیع بار به این صورت انجام می‌شود که بار کاری بین تمامی گره‌ها تقسیم می‌شود و هیچ گره‌ای در معرض بار اضافی قرار نمی‌گیرد.

---

پیکربندی کلاستر HA با استفاده از Pacemaker و Corosync

برای فعال‌سازی کلاستر HA، می‌توان از ابزارهای Pacemaker و Corosync استفاده کرد که به‌طور گسترده برای مدیریت کلاسترها و هماهنگی میان گره‌ها در سیستم‌های لینوکسی به‌کار می‌روند.

1. نصب ابزارهای موردنیازابتدا باید ابزارهای Pacemaker و Corosync را روی گره‌های مختلف نصب کنیم:

   sudo apt-get install pacemaker corosync
   

2. پیکربندی Corosyncفایل پیکربندی Corosync در مسیر /etc/corosync/corosync.conf قرار دارد. این فایل شامل تنظیمات مربوط به نام کلاستر و آدرس‌های IP گره‌ها است.برای ویرایش این فایل از دستور زیر استفاده می‌کنیم:

   sudo nano /etc/corosync/corosync.conf
   

   تنظیمات را به‌گونه‌ای وارد می‌کنیم که گره‌ها بتوانند به یکدیگر متصل شوند.

3. راه‌اندازی Pacemakerپس از پیکربندی Corosync، Pacemaker را راه‌اندازی می‌کنیم:

   sudo systemctl start pacemaker
   sudo systemctl enable pacemaker
   

4. ایجاد منابع HAحالا باید منابع HA خود را ایجاد کنیم. برای مثال، اگر بخواهیم سرویس HTTP را پیکربندی کنیم:

   sudo pcs resource create httpd ocf:heartbeat:apache
   

   این دستور سرویس HTTP را به‌صورت خودکار در کلاستر فعال می‌کند و آن را به گره‌های مختلف توزیع می‌کند.

5. بررسی وضعیت کلاستربرای بررسی وضعیت کلاستر و منابع آن، از دستور زیر استفاده می‌کنیم:

   sudo pcs status
   

   این دستور اطلاعات دقیقی از وضعیت گره‌ها و منابع موجود در کلاستر را به ما نمایش می‌دهد.

---

جمع‌بندی

کلاسترها در High Availability نقش اساسی در تأمین دسترس‌پذیری بالا دارند و به‌طور خودکار در صورت بروز خرابی، بار کاری را به گره‌های دیگر منتقل می‌کنند تا سرویس‌دهی بدون وقفه ادامه یابد. از طریق استفاده از Failover، Redundancy و Load Balancing، کلاسترها تضمین می‌کنند که سیستم‌ها همیشه در دسترس باقی بمانند و هیچ‌گونه وقفه‌ای در ارائه خدمات به کاربران ایجاد نشود. پیکربندی صحیح و مؤثر این سیستم‌ها با استفاده از ابزارهایی مانند Pacemaker و Corosync، اطمینان از عملکرد مداوم و بی‌وقفه را فراهم می‌آورد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”انواع مختلف کلاسترها: Active-Passive vs. Active-Active” subtitle=”توضیحات کامل”]کلاسترهای High Availability (HA) معمولاً به دو دسته اصلی تقسیم می‌شوند: Active-Passive و Active-Active. هر کدام از این انواع ویژگی‌های خاص خود را دارند و بسته به نیاز کسب‌وکار، انتخاب آن‌ها می‌تواند متفاوت باشد. در این بخش به تفاوت‌های این دو نوع کلاستر پرداخته و نحوه عملکرد هرکدام را توضیح می‌دهیم.

---

کلاستر Active-Passive

کلاسترهای Active-Passive به گونه‌ای طراحی می‌شوند که فقط یکی از گره‌ها به‌طور فعال و در حال سرویس‌دهی باشد، در حالی که سایر گره‌ها به‌طور غیرفعال (Passive) باقی می‌مانند و در حالت انتظار برای فعال شدن در مواقع خرابی قرار دارند. در این مدل، یک گره به‌عنوان گره فعال (Active) عمل می‌کند و تمامی بار کاری را مدیریت می‌کند، در حالی که گره‌های دیگر به‌صورت غیرفعال (Passive) در حالت آماده به کار باقی می‌مانند.

در صورت خرابی یا از کار افتادن گره فعال، گره غیرفعال به‌طور خودکار به حالت فعال تغییر وضعیت می‌دهد و بار کاری را بر عهده می‌گیرد. این فرآیند به‌عنوان Failover شناخته می‌شود.

مزایای کلاستر Active-Passive:

• سادگی پیاده‌سازی: پیاده‌سازی کلاسترهای Active-Passive معمولاً ساده‌تر است و به منابع کمتری نیاز دارد.
• هزینه کمتر: به دلیل اینکه تنها یک گره فعال است، هزینه‌های سخت‌افزاری و منابع کاهش می‌یابد.

معایب کلاستر Active-Passive:

• عدم استفاده بهینه از منابع: گره‌های غیرفعال به‌طور کامل از منابع خود استفاده نمی‌کنند و در واقع بیکار هستند.
• تأخیر در بازیابی: در صورت بروز خرابی، زمان لازم برای Failover ممکن است موجب اختلالات کوتاه‌مدت شود.

مثال‌های استفاده از کلاستر Active-Passive:

• سیستم‌های پایگاه داده که در آن‌ها فقط یک سرور اصلی برای پردازش داده‌ها و سایر سرورها به‌عنوان سرورهای پشتیبان عمل می‌کنند.
• سیستم‌های وب که در آن یک سرور اصلی برای سرویس‌دهی فعال است و در صورت خرابی به سرور پشتیبان منتقل می‌شود.

---

کلاستر Active-Active

در کلاسترهای Active-Active، تمامی گره‌ها به‌طور همزمان فعال هستند و بار کاری را به‌طور متوازن میان خود تقسیم می‌کنند. در این مدل، هر گره از کلاستر همزمان به پردازش داده‌ها و سرویس‌دهی به کاربران می‌پردازد. اگر یکی از گره‌ها دچار خرابی شود، گره‌های دیگر به‌طور خودکار بار کاری آن را به‌طور کامل به عهده می‌گیرند.

در این نوع کلاستر، همه گره‌ها فعال هستند و بار کاری میان آن‌ها تقسیم می‌شود. این باعث می‌شود که سیستم بتواند به‌طور مؤثرتر از منابع استفاده کرده و کارایی کلی سیستم بهبود یابد.

مزایای کلاستر Active-Active:

• استفاده بهینه از منابع: تمامی گره‌ها به‌طور فعال در حال استفاده از منابع هستند و بار کاری به‌طور متوازن توزیع می‌شود.
• پایداری و دسترس‌پذیری بالاتر: اگر یکی از گره‌ها دچار خرابی شود، گره‌های دیگر به‌طور خودکار بار کاری آن را بر عهده می‌گیرند، که این امر به پایداری و دسترس‌پذیری بیشتر کمک می‌کند.
• بهبود عملکرد: از آنجا که بار کاری بین گره‌ها توزیع می‌شود، امکان مقیاس‌پذیری و عملکرد بالاتر وجود دارد.

معایب کلاستر Active-Active:

• پیچیدگی بیشتر: پیاده‌سازی کلاستر Active-Active پیچیده‌تر است و نیاز به هماهنگی دقیق بین گره‌ها دارد.
• هزینه بالاتر: به دلیل اینکه تمامی گره‌ها به‌طور همزمان فعال هستند، نیاز به منابع بیشتری دارد و هزینه‌های سخت‌افزاری بیشتر می‌شود.

مثال‌های استفاده از کلاستر Active-Active:

• سیستم‌های پردازش تراکنش‌هایی مانند پردازش پرداخت‌ها که نیاز به پردازش مداوم و مقیاس‌پذیری دارند.
• وب‌سایت‌هایی که به‌طور مداوم بار زیادی دارند و نیاز به توزیع بار به‌طور مؤثر در بین سرورها دارند.

---

تفاوت‌های کلیدی بین کلاستر Active-Passive و Active-Active

ویژگی	کلاستر Active-Passive	کلاستر Active-Active
بار کاری	فقط یک گره فعال است و باقی گره‌ها غیرفعال هستند	تمامی گره‌ها فعال هستند و بار کاری بین آن‌ها توزیع می‌شود
پایداری و دسترس‌پذیری	پایین‌تر است چون در صورت خرابی تنها یک گره پشتیبان برای بازیابی است	پایداری و دسترس‌پذیری بالاتر به دلیل توزیع بار و قابلیت بازیابی سریع‌تر
پیچیدگی	ساده‌تر است	پیچیده‌تر است به دلیل هماهنگی و همگام‌سازی گره‌ها
هزینه	هزینه کمتری دارد	هزینه بالاتر به دلیل نیاز به منابع بیشتر
مقیاس‌پذیری	محدود به گره فعال و غیرفعال	مقیاس‌پذیری بیشتر به دلیل استفاده از تمامی گره‌ها

---

جمع‌بندی

کلاسترهای Active-Passive و Active-Active هرکدام مزایا و معایب خاص خود را دارند. انتخاب بین این دو مدل به نیازهای خاص سیستم، میزان ترافیک، پیچیدگی و منابع موجود بستگی دارد. کلاسترهای Active-Passive ساده‌تر و کم‌هزینه‌تر هستند ولی مقیاس‌پذیری و پایداری کمتری دارند. از سوی دیگر، کلاسترهای Active-Active عملکرد بالاتر، استفاده بهینه‌تر از منابع و پایداری بیشتر را فراهم می‌آورند، اما به دلیل پیچیدگی‌های بیشتر، نیاز به منابع و هزینه‌های بالاتری دارند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 6. اصول معماری کلاسترهای HA”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”نحوه معماری یک کلاستر HA” subtitle=”توضیحات کامل”]کلاستر High Availability (HA) به‌عنوان یکی از تکنیک‌های اصلی در طراحی سیستم‌های پایدار و مقاوم در برابر خرابی‌ها، به‌گونه‌ای ساخته می‌شود که اطمینان حاصل کند سرویس‌ها و منابع سیستم در هر لحظه در دسترس هستند. معماری کلاستر HA معمولاً شامل چندین گره (nodes) است که به‌طور هماهنگ با هم کار می‌کنند تا در صورت بروز خرابی در یک گره، سیستم به‌طور خودکار به گره‌های دیگر منتقل شود.

در این بخش، نحوه معماری یک کلاستر HA را بررسی می‌کنیم، به‌ویژه نحوه تعامل گره‌ها و اجزای مختلف سیستم.

---

اجزای اصلی معماری کلاستر HA

1. گره‌های کلاستر (Cluster Nodes):
   یک کلاستر HA معمولاً شامل دو یا بیشتر گره است. این گره‌ها ممکن است در یک سرور فیزیکی یا مجازی قرار داشته باشند، و هر کدام از گره‌ها می‌تواند نقش خاص خود را در سرویس‌دهی به کاربران ایفا کند. گره‌ها ممکن است به‌صورت Active-Passive یا Active-Active تنظیم شوند.
2. مدیر کلاستر (Cluster Manager):
   این نرم‌افزار مسئول نظارت بر وضعیت گره‌ها و تصمیم‌گیری در مورد تغییرات وضعیت گره‌ها (مانند Failover) است. مدیر کلاستر به‌طور مداوم وضعیت هر گره را بررسی می‌کند و در صورت شناسایی خرابی، تصمیم به انتقال بار به گره‌های سالم می‌گیرد.
3. شبکه‌ها (Networking):
   در کلاستر HA، تمامی گره‌ها باید از یک شبکه سریع و قابل اطمینان برای ارتباط با یکدیگر استفاده کنند. این شبکه، به‌ویژه در زمان Failover، باید توانایی انتقال داده‌ها و درخواست‌ها به گره‌های پشتیبان را بدون تأخیر زیاد فراهم کند.
4. ذخیره‌سازی مشترک (Shared Storage):
   در اکثر کلاسترهای HA، تمامی گره‌ها به یک سیستم ذخیره‌سازی مشترک دسترسی دارند. این ذخیره‌سازی می‌تواند شامل دیسک‌های SAN (Storage Area Network) یا NAS (Network-Attached Storage) باشد. هدف از استفاده از ذخیره‌سازی مشترک این است که داده‌ها در تمامی گره‌ها در دسترس باشند، حتی اگر یکی از گره‌ها از کار بیفتد.
5. Failover:
   یکی از ویژگی‌های اصلی در معماری کلاستر HA، Failover است. زمانی که گره فعال دچار خرابی شود، گره‌های دیگر به‌طور خودکار بار کاری آن را به عهده می‌گیرند. این انتقال باید به‌صورت خودکار و بدون نیاز به مداخله دستی انجام شود.
6. Heartbeat (سیگنال زنده بودن):
   گره‌ها به‌طور مداوم سیگنال‌های Heartbeat را برای یکدیگر ارسال می‌کنند تا از سلامت و دسترس‌پذیری یکدیگر مطمئن شوند. اگر یکی از گره‌ها نتواند سیگنال‌های Heartbeat را ارسال کند، به‌عنوان یک گره خرابی تشخیص داده شده و فرآیند Failover آغاز می‌شود.

---

فرآیند Failover در کلاستر HA

1. تشخیص خرابی:
   گره‌های کلاستر به‌طور مداوم وضعیت گره‌ها را نظارت می‌کنند. این نظارت از طریق ارسال سیگنال‌های Heartbeat انجام می‌شود. اگر گره‌ای نتواند سیگنال Heartbeat را ارسال کند یا در صورت خرابی سخت‌افزاری، نرم‌افزاری یا شبکه‌ای شناسایی شود، گره‌ها به‌صورت خودکار فرآیند Failover را آغاز می‌کنند.
2. انتقال بار به گره‌های دیگر:
   پس از تشخیص خرابی، سیستم به‌طور خودکار بار کاری گره خراب را به گره‌های سالم انتقال می‌دهد. این فرآیند معمولاً با استفاده از نرم‌افزارهای مدیریت کلاستر و ابزارهای ذخیره‌سازی مشترک انجام می‌شود.
3. برگشت به حالت عادی (Failback):
   زمانی که گره خراب شده دوباره به حالت آنلاین باز می‌گردد و مشکلات آن رفع می‌شود، بار کاری به‌طور مجدد به آن گره باز می‌گردد. این فرآیند به‌نام Failback شناخته می‌شود و می‌تواند به‌طور خودکار یا دستی انجام شود.

---

نحوه پیاده‌سازی معماری کلاستر HA

در اینجا مثالی از نحوه پیاده‌سازی معماری کلاستر HA با استفاده از دو گره (Active-Passive) آورده شده است:

1. نصب و راه‌اندازی گره‌ها:
   • گره 1 (Active): این گره به‌طور معمول سرویس‌دهی را انجام می‌دهد.
   • گره 2 (Passive): این گره آماده برای پذیرش بار در صورت خرابی گره 1 است.
2. پیکربندی شبکه و ذخیره‌سازی مشترک:
   • از یک سیستم ذخیره‌سازی مشترک مانند NAS یا SAN برای ذخیره‌سازی داده‌ها استفاده می‌شود.
   • هر دو گره به این ذخیره‌سازی مشترک متصل هستند تا داده‌ها در صورت Failover در دسترس باشند.
3. نصب و پیکربندی نرم‌افزار کلاستر: نرم‌افزارهای مدیریت کلاستر مانند Pacemaker (در لینوکس) یا Microsoft Failover Cluster (در ویندوز) نصب می‌شوند. این نرم‌افزار مسئول نظارت بر وضعیت گره‌ها و فرآیند Failover است.
4. پیکربندی Heartbeat و Failover:
   • نرم‌افزار Heartbeat برای نظارت بر وضعیت گره‌ها و ارسال سیگنال‌های زنده بودن پیکربندی می‌شود.
   • فرآیند Failover به‌طور خودکار فعال می‌شود تا زمانی که گره 1 دچار خرابی شود، گره 2 به‌طور خودکار بار کاری را بر عهده گیرد.

---

جمع‌بندی

معماری یک کلاستر HA از چندین جزء اصلی تشکیل می‌شود که شامل گره‌ها، نرم‌افزارهای مدیریت کلاستر، ذخیره‌سازی مشترک، شبکه‌های ارتباطی، و فرآیندهای Failover و Heartbeat است. این معماری به‌گونه‌ای طراحی می‌شود که در صورت خرابی یکی از گره‌ها، سیستم به‌طور خودکار به گره‌های سالم منتقل شده و سرویس‌دهی به کاربران ادامه یابد. پیاده‌سازی این کلاسترها بستگی به نیاز کسب‌وکار و منابع موجود دارد، اما هدف اصلی آن فراهم کردن دسترس‌پذیری بالا و پایداری سیستم است.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”ارتباطات و هماهنگی میان گره‌ها” subtitle=”توضیحات کامل”]در سیستم‌های High Availability (HA)، ارتباطات و هماهنگی میان گره‌ها از جمله عوامل حیاتی برای عملکرد درست و مطمئن سیستم است. این ارتباطات باید به‌گونه‌ای طراحی شوند که در صورت خرابی یکی از گره‌ها، دیگر گره‌ها بتوانند بلافاصله بار را به دوش بگیرند و سرویس‌دهی بدون وقفه ادامه یابد. در این بخش به بررسی نحوه ایجاد و مدیریت ارتباطات میان گره‌ها، شامل پیکربندی و تنظیمات مربوطه می‌پردازیم.

---

1. ارتباطات شبکه‌ای میان گره‌ها

برای اینکه گره‌ها بتوانند به‌طور مؤثر با یکدیگر همکاری کنند، باید یک شبکه سریع و پایدار برای انتقال داده‌ها و سیگنال‌های Heartbeat وجود داشته باشد. این ارتباطات به‌ویژه در زمان Failover و بررسی وضعیت سلامت گره‌ها اهمیت زیادی دارد.

در اکثر سیستم‌های HA، گره‌ها باید قادر باشند به‌صورت دوطرفه و با تأخیر کم به‌یکدیگر اطلاعات ارسال کنند. این اطلاعات شامل سیگنال‌های زنده بودن (Heartbeat)، وضعیت ذخیره‌سازی و درخواست‌های Failover است.

برای پیکربندی ارتباطات شبکه‌ای میان گره‌ها، معمولاً از ابزارهای مختلف نظیر Heartbeat و Corosync در سیستم‌های لینوکسی استفاده می‌شود.

---

2. پیکربندی ارتباطات شبکه‌ای با استفاده از Heartbeat

برای تنظیم ارتباطات شبکه‌ای و ارسال سیگنال‌های Heartbeat بین گره‌ها، ابتدا باید نرم‌افزار Heartbeat را نصب و پیکربندی کنید.

مرحله 1: نصب Heartbeat

ابتدا برای نصب Heartbeat در هر گره، از دستور زیر استفاده می‌کنیم:

sudo apt-get update
sudo apt-get install heartbeat

این دستور Heartbeat را نصب می‌کند.

مرحله 2: پیکربندی فایل‌ها

در هر گره، باید پیکربندی مربوط به Heartbeat را تنظیم کنید. برای این کار، فایل‌های پیکربندی زیر را ویرایش می‌کنیم:

• /etc/ha.d/ha.cf: این فایل تنظیمات اصلی ارتباطات شبکه‌ای را شامل می‌شود.
• /etc/ha.d/haresources: در این فایل منابعی که باید توسط کلاستر مدیریت شوند، معرفی می‌شوند.

در فایل ha.cf، خطوط زیر را اضافه می‌کنیم:

logfacility local0
heartbeat 10
deadtime 30
bcast eth0

• heartbeat 10: فاصله زمانی بین سیگنال‌های Heartbeat است (در ثانیه).
• deadtime 30: مدت زمانی که پس از عدم دریافت Heartbeat از یک گره، آن گره به‌عنوان خراب شناخته می‌شود.
• bcast eth0: این گزینه برای ارسال سیگنال‌های Heartbeat از طریق شبکه استفاده می‌شود. در اینجا، از اینترفیس eth0 برای ارسال سیگنال‌ها استفاده می‌کنیم.

در فایل haresources، باید منابع و گره‌های فعال و پشتیبان را تنظیم کنیم:

node1 IPaddr::192.168.1.100/24/eth0
node2 IPaddr::192.168.1.101/24/eth0

• IPaddr::192.168.1.100/24/eth0: این خط به سیستم اعلام می‌کند که IP مورد نظر برای گره‌ها باید به‌صورت اشتراکی در دسترس باشد.

مرحله 3: راه‌اندازی Heartbeat

پس از اعمال تغییرات در فایل‌ها، می‌توانیم سرویس Heartbeat را راه‌اندازی کنیم:

sudo systemctl start heartbeat
sudo systemctl enable heartbeat

این دستورات سرویس Heartbeat را راه‌اندازی و در هنگام راه‌اندازی سیستم به‌طور خودکار فعال می‌کند.

---

3. استفاده از Corosync برای هماهنگی گره‌ها

Corosync یکی دیگر از ابزارهای مهم برای هماهنگی میان گره‌ها در کلاسترهای HA است. Corosync به‌عنوان یک راه‌حل پیام‌رسانی میان گره‌ها، علاوه بر ارسال سیگنال‌های Heartbeat، از لحاظ همزمانی داده‌ها، کشف گره‌ها و مدیریت وضعیت نیز عمل می‌کند.

برای نصب Corosync در سیستم‌های لینوکس، ابتدا از دستور زیر استفاده می‌کنیم:

sudo apt-get install corosync

سپس، پیکربندی فایل /etc/corosync/corosync.conf را به‌صورت زیر انجام می‌دهیم:

totem {
    version: 2
    cluster_name: ha_cluster
    secauth: off
    interface {
        ringnumber: 0
        bindnetaddr: 192.168.1.0
        mcastaddr: 239.255.1.1
        mcastport: 5405
    }
}

nodelist {
    node {
        ring0_addr: node1
        nodeid: 1
    }
    node {
        ring0_addr: node2
        nodeid: 2
    }
}

• bindnetaddr: 192.168.1.0: آدرس شبکه برای برقراری ارتباط میان گره‌ها.
• mcastaddr: 239.255.1.1: آدرس چندپخشی برای ارسال پیام‌ها به تمام گره‌ها.
• nodelist: در این قسمت باید مشخص کنیم که هر گره چه نامی دارد و کدام آدرس برای ارتباط استفاده خواهد شد.

پس از ویرایش پیکربندی، Corosync را راه‌اندازی می‌کنیم:

sudo systemctl start corosync
sudo systemctl enable corosync

---

4. نظارت بر وضعیت گره‌ها

در معماری‌های HA، نظارت دقیق بر وضعیت هر گره و منابع مربوطه از اهمیت ویژه‌ای برخوردار است. برای انجام این کار، ابزارهای مختلفی مانند crm و pcs (برای مدیریت کلاسترهای Pacemaker) استفاده می‌شود.

برای مشاهده وضعیت کلاستر، دستور زیر را وارد می‌کنیم:

sudo crm status

این دستور وضعیت تمامی گره‌ها و منابع را در کلاستر به‌طور خلاصه نشان می‌دهد.

---

جمع‌بندی

در کلاسترهای High Availability (HA)، ارتباطات و هماهنگی میان گره‌ها برای عملکرد صحیح و پایدار سیستم بسیار حیاتی است. این ارتباطات از طریق ابزارهایی مانند Heartbeat و Corosync انجام می‌شود که وظیفه نظارت بر سلامت گره‌ها و هماهنگ‌سازی اطلاعات میان گره‌ها را دارند. برای پیاده‌سازی این سیستم‌ها، نیاز به پیکربندی صحیح شبکه، تنظیمات ارتباطی و نظارت دقیق بر وضعیت گره‌ها است. پیکربندی‌های مربوطه باید در فایل‌های خاص سیستم تنظیم شوند و بعد از اعمال تغییرات، سرویس‌ها باید به‌طور صحیح راه‌اندازی شوند تا در صورت خرابی، سیستم به‌طور خودکار انتقال بار را انجام دهد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”نحوه توزیع بار بین گره‌ها و مکانیزم‌های مدیریت منابع” subtitle=”توضیحات کامل”]در محیط‌های High Availability (HA)، توزیع بار و مدیریت منابع به‌طور مستقیم بر کارایی، پایداری و دسترس‌پذیری سیستم تأثیر می‌گذارد. هدف از توزیع بار بین گره‌ها این است که از ظرفیت تمام گره‌ها استفاده بهینه شود و در صورت بروز خرابی در یک گره، بار به‌طور خودکار به گره‌های سالم منتقل شود. برای مدیریت منابع نیز باید از مکانیسم‌هایی استفاده کرد که از همگام‌سازی داده‌ها و تخصیص منابع به‌طور بهینه و کارآمد پشتیبانی کنند.

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

---

1. توزیع بار در کلاسترهای HA

توزیع بار میان گره‌ها به‌معنای توزیع درخواست‌های سرویس‌دهی به چندین گره است تا هیچ گره‌ای به‌تنهایی بار زیادی را تحمل نکند و در صورت خرابی، سیستم همچنان قادر به پاسخگویی به درخواست‌ها باشد.

روش‌های توزیع بار در کلاسترهای HA:

1. Round-robin Load Balancing: در این روش، درخواست‌ها به‌طور دوره‌ای به گره‌ها ارسال می‌شود. هر درخواست جدید به گره بعدی در صف تخصیص داده می‌شود. این روش برای شرایطی مناسب است که گره‌ها دارای ظرفیت مشابهی باشند.مثال: در هنگام راه‌اندازی یک کلاستر HA با استفاده از Nginx یا HAProxy به‌عنوان Load Balancer، این روش به‌طور خودکار درخواست‌ها را میان گره‌ها به‌صورت مساوی توزیع می‌کند.
2. Least Connections: در این روش، درخواست‌ها به گره‌ای ارسال می‌شوند که کمترین تعداد ارتباطات فعال را داشته باشد. این روش معمولاً در شرایطی استفاده می‌شود که گره‌ها دارای منابع مختلف (مثل CPU یا حافظه) هستند و برخی از گره‌ها ممکن است قادر به مدیریت بار بیشتری باشند.
3. IP Hashing: در این روش، تخصیص بار به گره‌ها بر اساس IP درخواست‌دهنده انجام می‌شود. هر IP به یک گره خاص تخصیص داده می‌شود تا همواره درخواست‌های مرتبط به یک IP خاص به همان گره ارسال شوند.

پیکربندی توزیع بار با استفاده از HAProxy

در صورتی که از HAProxy برای توزیع بار استفاده کنید، می‌توانید از روش‌های مختلف توزیع بار مانند Round-robin، Least Connections و IP Hashing استفاده کنید.

مرحله 1: نصب HAProxy

sudo apt-get update
sudo apt-get install haproxy

مرحله 2: پیکربندی HAProxy

در فایل پیکربندی HAProxy که معمولاً در مسیر /etc/haproxy/haproxy.cfg قرار دارد، تنظیمات توزیع بار به شرح زیر انجام می‌شود:

frontend http_front
    bind *:80
    default_backend http_back

backend http_back
    balance roundrobin
    server server1 192.168.1.101:80 check
    server server2 192.168.1.102:80 check

در این پیکربندی:

• balance roundrobin: از روش Round-robin برای توزیع بار استفاده می‌شود.
• server server1 192.168.1.101:80 check: درخواست‌ها به آدرس IP 192.168.1.101 ارسال می‌شوند.
• server server2 192.168.1.102:80 check: درخواست‌ها به آدرس IP 192.168.1.102 ارسال می‌شوند.

مرحله 3: راه‌اندازی HAProxy

sudo systemctl restart haproxy
sudo systemctl enable haproxy

---

2. مکانیزم‌های مدیریت منابع

مدیریت منابع در سیستم‌های HA به‌منظور اطمینان از تخصیص بهینه منابع به گره‌ها و جلوگیری از ایجاد بار زیاد روی یک گره خاص انجام می‌شود. این مدیریت معمولاً با استفاده از ابزارهای مختلف و با در نظر گرفتن نیازهای متنوع مانند حافظه، پردازنده و پهنای باند انجام می‌شود.

مکانیزم‌های مدیریت منابع شامل موارد زیر هستند:

1. Pacemaker: Pacemaker یکی از ابزارهای محبوب برای مدیریت کلاسترهای HA است. این ابزار امکان مدیریت منابع مانند IP آدرس‌ها، سرویس‌ها و دیسک‌ها را فراهم می‌آورد و در صورت خرابی یکی از گره‌ها، بار را به گره‌های سالم منتقل می‌کند.پیکربندی منابع با استفاده از Pacemaker:در ابتدا باید از ابزار crm برای مدیریت منابع استفاده کنیم. به‌طور مثال برای اضافه کردن یک سرویس به کلاستر، دستور زیر را وارد می‌کنیم:

   sudo crm configure
   primitive MyService ocf:heartbeat:apache
   

   این دستور سرویس Apache را به کلاستر اضافه می‌کند و در صورت خرابی، Pacemaker سرویس را به گره‌های دیگر منتقل می‌کند.

2. Cgroups (Control Groups): Cgroups ابزاری است که برای تخصیص منابع سیستم (مانند CPU، حافظه و I/O) به پروسه‌ها و گره‌ها استفاده می‌شود. این ابزار به کلاسترهای HA این امکان را می‌دهد که منابع را به‌طور دقیق‌تر مدیریت کنند و از ایجاد بار اضافی روی گره‌ها جلوگیری کنند.پیکربندی Cgroups:برای ایجاد و مدیریت Cgroups، از دستور زیر استفاده می‌کنیم:

   sudo cgcreate -g memory,cpu:mygroup
   sudo cgset -r memory.limit_in_bytes=512M mygroup
   sudo cgset -r cpu.shares=512 mygroup
   

   در اینجا:

   • memory.limit_in_bytes=512M: محدود کردن استفاده از حافظه به 512 مگابایت.
   • cpu.shares=512: تخصیص نصف منابع CPU به گروه mygroup.
3. Resource Allocation in Kubernetes: در محیط‌های مدرن Containerized مانند Kubernetes، منابع به‌طور خودکار تخصیص می‌یابند. Kubernetes از Podها برای اجرای برنامه‌ها استفاده می‌کند و می‌توان منابع مانند CPU، حافظه و پهنا‌ی باند را به‌طور دقیق برای هر Pod مشخص کرد.پیکربندی منابع در Kubernetes:برای تخصیص منابع به یک Pod در Kubernetes، می‌توانیم از فایل YAML استفاده کنیم:

   apiVersion: v1
   kind: Pod
   metadata:
     name: mypod
   spec:
     containers:
     - name: mycontainer
       image: nginx
       resources:
         requests:
           memory: "256Mi"
           cpu: "250m"
         limits:
           memory: "512Mi"
           cpu: "500m"
   

   در این پیکربندی:

   • requests: مقدار حداقل منابع مورد نیاز برای اجرای کانتینر.
   • limits: مقدار حداکثر منابع که می‌تواند توسط کانتینر استفاده شود.

---

جمع‌بندی

توزیع بار و مدیریت منابع در کلاسترهای High Availability (HA) نقش کلیدی در افزایش پایداری، کارایی و دسترس‌پذیری سیستم ایفا می‌کنند. توزیع بار میان گره‌ها باعث می‌شود که بار به‌طور متوازن در تمام گره‌ها پخش شود و در صورت خرابی یک گره، سیستم به‌طور خودکار به گره‌های سالم منتقل شود. همچنین، مکانیزم‌های مدیریت منابع مانند Pacemaker و Cgroups به‌طور مؤثر منابع را تخصیص داده و از ایجاد بار زیاد روی گره‌ها جلوگیری می‌کنند. استفاده از ابزارهای مختلف مانند HAProxy، Pacemaker و Kubernetes برای مدیریت منابع و توزیع بار در محیط‌های HA ضروری است.[/cdb_course_lesson][cdb_course_lesson title=”فصل 7. اجزای مختلف یک کلاستر HA”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”بررسی اجزای مختلف یک کلاستر HA” subtitle=”توضیحات کامل”]کلاسترهای High Availability (HA) مجموعه‌ای از گره‌ها هستند که به‌طور هماهنگ و منظم کار می‌کنند تا از دسترس‌پذیری مداوم و پایدار خدمات اطمینان حاصل شود. این گره‌ها می‌توانند شامل سرورها، منابع ذخیره‌سازی و شبکه‌های ارتباطی باشند که در یک کلاستر برای دستیابی به هدف HA، به‌طور مشترک عمل می‌کنند. اجزای مختلف یک کلاستر HA شامل Node ها (گره‌ها)، ارتباطات میان گره‌ها (Cluster Communication)، مدیریت منابع (Cluster Resource Manager) و مکانیزم‌های جابجایی (Failover) هستند.

---

1. Cluster Nodes: گره‌ها و نقش‌های آن‌ها در کلاستر

در یک کلاستر HA، گره‌ها واحدهای اصلی هستند که وظایف مختلف را به عهده دارند. این گره‌ها ممکن است در قالب سرورهای فیزیکی یا مجازی باشند و می‌توانند نقش‌های مختلفی در کلاستر ایفا کنند.

انواع گره‌ها در کلاستر HA:

1. Active Nodes: گره‌های فعال وظیفه پردازش درخواست‌ها و خدمات را بر عهده دارند. معمولاً یکی یا چند گره به‌طور همزمان فعال هستند و تمامی درخواست‌های ورودی را به‌طور مستقیم پردازش می‌کنند.
2. Passive Nodes: گره‌های غیرفعال یا پشتیبان در حالت انتظار هستند. این گره‌ها به‌طور مستقیم هیچ‌گونه خدماتی ارائه نمی‌دهند و تنها در صورت بروز خرابی در گره‌های فعال، به‌طور خودکار فعال شده و وظایف را بر عهده می‌گیرند.
3. Master/Primary Nodes: گره‌های اصلی که داده‌ها و منابع اصلی را مدیریت می‌کنند. در کلاسترهایی با Replication، این گره‌ها به‌عنوان منابع اصلی داده عمل می‌کنند.
4. Slave/Secondary Nodes: گره‌های پشتیبان که نسخه‌ای از داده‌ها و منابع را از گره‌های اصلی دریافت می‌کنند و در صورت خرابی گره‌های اصلی، به‌طور خودکار وظایف را بر عهده می‌گیرند.

پیکربندی گره‌ها در کلاستر:

در بیشتر کلاسترها، برای تنظیم یک گره به‌عنوان گره فعال یا غیرفعال، باید تنظیمات خاصی در فایل‌های پیکربندی مانند Pacemaker یا Corosync اعمال شود. این فایل‌ها معمولاً در مسیر /etc/pacemaker قرار دارند.

---

2. Cluster Communication: سیستم‌های ارتباطی میان گره‌ها

ارتباطات میان گره‌ها بخش حیاتی هر کلاستر HA است. گره‌ها باید اطلاعات مربوط به وضعیت خود و سایر گره‌ها را به‌طور مداوم مبادله کنند تا کلاستر بتواند تصمیمات مناسبی در هنگام وقوع خرابی یا نیاز به تغییر وضعیت گره‌ها اتخاذ کند.

انواع ارتباطات در کلاستر HA:

1. Corosync: Corosync یک پروتکل است که ارتباطات بین گره‌های کلاستر را مدیریت می‌کند. این ابزار به‌ویژه برای کلاسترهای مبتنی بر Pacemaker استفاده می‌شود. Corosync تضمین می‌کند که گره‌ها از وضعیت دیگر گره‌ها مطلع باشند.پیکربندی Corosync: در فایل پیکربندی Corosync، تنظیمات مربوط به نحوه ارتباط گره‌ها و تنظیمات فنی شبکه‌ای انجام می‌شود. فایل پیکربندی معمولاً در مسیر /etc/corosync/corosync.conf قرار دارد.مثال:

   totem {
     version: 2
     config_version: 2
     token: 5000
     token_retransmits_before_loss_const: 10
     clear_node_high_bit: yes
     interface {
       ringnumber: 0
       bindnetaddr: 192.168.1.0
       mcastaddr: 226.94.1.1
       mcastport: 5405
     }
   }
   

2. Heartbeat: Heartbeat نیز یکی از پروتکل‌های ارتباطی است که معمولاً در کلاسترهای HA برای نظارت بر وضعیت گره‌ها استفاده می‌شود. این پروتکل اطلاعات وضعیت گره‌ها را ارسال کرده و در صورت بروز خرابی در یک گره، اقدام به جابجایی آن به گره دیگر می‌کند.

---

3. Cluster Resource Manager (CRM): مدیریت منابع در کلاستر

مدیریت منابع در یک کلاستر HA به عهده Cluster Resource Manager (CRM) است. CRM وظیفه نظارت و مدیریت منابع مختلف مانند IP آدرس‌ها، سرویس‌ها، منابع ذخیره‌سازی و سایر منابع را به عهده دارد.

وظایف Cluster Resource Manager:

• نظارت بر منابع مختلف در کلاستر.
• تعیین گره‌ای که باید منابع خاصی را مدیریت کند.
• جابجایی منابع از یک گره به گره دیگر در صورت بروز خرابی.
• مدیریت وضعیت منابع و اجرای اقدامات پیش‌فرض مانند راه‌اندازی مجدد منابع در گره‌های دیگر.

پیکربندی Cluster Resource Manager با استفاده از Pacemaker:

برای تنظیم CRM در کلاستر، باید از ابزار crm استفاده کرد. به‌عنوان مثال برای اضافه کردن یک سرویس به کلاستر، دستور زیر را وارد می‌کنیم:

sudo crm configure
primitive MyService ocf:heartbeat:apache

در این پیکربندی:

• primitive: یک نوع منبع خاص را تعریف می‌کند.
• ocf:heartbeat:apache: منبع برای سرویس Apache است.

---

4. Failover Mechanisms: مکانیزم‌های جابجایی در صورت بروز خرابی

Failover به‌معنای انتقال کارکردها و وظایف از یک گره به گره دیگر در صورت بروز خرابی است. در کلاسترهای HA، هنگامی که یک گره دچار خرابی می‌شود، تمام خدمات و منابع آن گره به‌طور خودکار به گره‌های سالم منتقل می‌شوند تا از قطعی سرویس‌ها جلوگیری شود.

انواع مکانیزم‌های Failover:

1. Automated Failover: این مکانیزم به‌طور خودکار و بدون نیاز به مداخله دستی، بار را از گره خراب‌شده به گره‌های سالم منتقل می‌کند. ابزارهایی مانند Pacemaker و Corosync این مکانیزم را به‌طور خودکار پیاده‌سازی می‌کنند.
2. Manual Failover: در این مکانیزم، خرابی گره باید به‌طور دستی شناسایی و سپس اقدام به جابجایی منابع و سرویس‌ها به گره‌های دیگر انجام شود. این روش معمولاً در شرایط خاص یا در صورتی که مکانیزم‌های خودکار پاسخگو نباشند، استفاده می‌شود.

پیکربندی Failover با استفاده از Pacemaker:

در تنظیمات Pacemaker، زمانی که یک گره دچار خرابی می‌شود، منبع مربوط به آن گره به‌طور خودکار به گره دیگر منتقل می‌شود. برای پیکربندی failover در Pacemaker از دستور زیر استفاده می‌شود:

sudo crm configure primitive WebServer ocf:heartbeat:apache op monitor interval=30s

در اینجا:

• op monitor interval=30s: نظارت بر وضعیت سرویس Apache هر ۳۰ ثانیه یک‌بار.
• در صورت خرابی گره‌ای که سرویس Apache را مدیریت می‌کند، این سرویس به گره دیگر منتقل می‌شود.

---

جمع‌بندی

کلاسترهای High Availability (HA) از اجزای مختلفی تشکیل شده‌اند که به‌طور هماهنگ با هم کار می‌کنند. گره‌ها (Cluster Nodes) نقش مهمی در پردازش درخواست‌ها دارند، ارتباطات میان گره‌ها (Cluster Communication) از طریق پروتکل‌هایی مانند Corosync و Heartbeat صورت می‌گیرد، و Cluster Resource Manager (CRM) مسئول نظارت و مدیریت منابع در کلاستر است. همچنین مکانیزم‌های Failover برای جابجایی منابع و خدمات در صورت خرابی گره‌ها، از اهمیت ویژه‌ای برخوردار هستند. تمامی این اجزا با هم در هماهنگی کامل کار می‌کنند تا از پایداری و در دسترس‌پذیری سیستم‌ها و سرویس‌ها در محیط‌های HA اطمینان حاصل شود.[/cdb_course_lesson][cdb_course_lesson title=”فصل 8. چالش‌ها و نیازها در پیاده‌سازی HA در لینوکس”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”نیاز به هماهنگی بین اجزای مختلف سیستم” subtitle=”توضیحات کامل”]پیاده‌سازی High Availability (HA) در سیستم‌های لینوکسی به‌ویژه در محیط‌های پیچیده و مقیاس‌پذیر می‌تواند چالش‌برانگیز باشد. از جمله چالش‌های اصلی می‌توان به نیاز به هماهنگی بین اجزای مختلف سیستم اشاره کرد که در این بخش به‌طور ویژه بر این موضوع تمرکز می‌کنیم.

نیاز به هماهنگی بین اجزای مختلف سیستم

در کلاسترهای HA، اجزای مختلف باید به‌طور هماهنگ عمل کنند تا از در دسترس‌پذیری مداوم سرویس‌ها اطمینان حاصل شود. این هماهنگی نه‌تنها در سطح نرم‌افزار، بلکه در سطح سخت‌افزار، شبکه و منابع نیز ضروری است.

چالش‌ها و نیازها در هماهنگی بین اجزای سیستم عبارتند از:

1. هماهنگی منابع ذخیره‌سازی: یکی از مهم‌ترین چالش‌ها در پیاده‌سازی HA، اطمینان از هماهنگی منابع ذخیره‌سازی است. زمانی که منابع ذخیره‌سازی مانند دیسک‌ها یا سیستم‌های فایل بین گره‌ها به اشتراک گذاشته می‌شود، باید مکانیزم‌هایی برای همگام‌سازی داده‌ها وجود داشته باشد.
   • به‌روزرسانی داده‌ها: وقتی یک گره خراب می‌شود و منابع به گره دیگر منتقل می‌شود، اطمینان از اینکه داده‌ها و وضعیت‌ها به‌طور صحیح در گره جدید بازسازی شوند، مهم است. این کار نیاز به ابزارهایی مانند DRBD (Distributed Replicated Block Device) یا GlusterFS دارد.
   • نظارت بر وضعیت داده‌ها: داده‌ها باید به‌طور مداوم و با کمترین تأخیر در گره‌های مختلف همگام شوند.
2. هماهنگی بین گره‌ها: گره‌ها در یک کلاستر HA باید با هم هماهنگ باشند تا تصمیمات مربوط به failover، load balancing، و resource management به درستی اتخاذ شوند. این هماهنگی به‌شدت تحت تأثیر سیستم‌های ارتباطی میان گره‌ها مانند Pacemaker و Corosync است.
   • مسائل شبکه‌ای: به‌منظور هماهنگی دقیق، باید تأخیر و بسته‌های گمشده شبکه‌ای را به حداقل رساند. شبکه باید بدون قطعی یا تأخیر زیاد عمل کند تا وضعیت هر گره به‌طور صحیح و به‌موقع به سایر گره‌ها گزارش شود.
   • پیکربندی شبکه: پیکربندی درست آدرس‌های IP و Subnet ها و همچنین ایجاد تنظیمات صحیح برای ارتباطات multicast یا unicast بین گره‌ها اهمیت دارد.
3. هماهنگی در زمان‌بندی failover: در هنگام خرابی یک گره، باید مکانیزم‌هایی وجود داشته باشد تا فرآیند انتقال منابع و خدمات به گره جدید به‌صورت هم‌زمان و سریع انجام شود. زمان‌بندی مناسب یکی از چالش‌های بزرگ است، زیرا تأخیر در failover می‌تواند باعث ایجاد وقفه یا قطعی در سرویس‌ها شود.
   • زمان مناسب برای Failover: باید حداقل زمان ممکن برای شناسایی خرابی و جابجایی منابع وجود داشته باشد. برای این کار باید ابزارهای نظارت و مدیریت منابع مانند Pacemaker و Corosync پیکربندی شوند تا در سریع‌ترین زمان ممکن، وضعیت خرابی گره را تشخیص دهند و به گره دیگر منتقل کنند.
   • هماهنگی بین گره‌های Active و Passive: گره‌های فعال و غیرفعال باید به‌طور مستمر وضعیت یکدیگر را بررسی کرده و اطلاعات لازم را در زمان واقعی مبادله کنند.
4. مدیریت منابع: منابع مختلف در کلاستر باید به‌طور صحیح مدیریت شوند. از منابع شبکه و پردازشگر گرفته تا منابع ذخیره‌سازی، همگی باید در دسترس باشند و در صورت خرابی هرکدام، به گره‌های دیگر منتقل شوند. Cluster Resource Manager (CRM) به‌عنوان ابزار اصلی برای این کار، باید به‌دقت پیکربندی شود.
   • مدیریت منابع مشترک: منابعی که بین گره‌ها به اشتراک گذاشته می‌شوند مانند IP‌های مجازی (Virtual IP) یا گواهی‌های SSL باید به‌طور کامل هماهنگ و مدیریت شوند.
   • پیکربندی منابع: هر منبع در کلاستر باید به‌طور جداگانه تعریف شده و برای failover و مدیریت آن در صورت خرابی تنظیم شود.
5. هماهنگی نرم‌افزارهای مختلف: در یک کلاستر HA ممکن است نرم‌افزارهای مختلفی برای load balancing، replication، failover و resource management استفاده شوند. این نرم‌افزارها باید به‌طور یکپارچه با هم کار کنند تا هماهنگی بین گره‌ها و منابع به درستی برقرار شود.
   • هماهنگی ابزارهای نرم‌افزاری: ابزارهایی مانند HAProxy برای توزیع بار، Pacemaker برای مدیریت منابع، و DRBD برای همگام‌سازی داده‌ها باید به‌طور صحیح با هم در ارتباط باشند.
   • پیکربندی صحیح: انتخاب ابزارها باید متناسب با نیازهای کلاستر و پیاده‌سازی آن باشد. برخی ابزارها ممکن است تنها برای برخی سناریوها مناسب باشند، بنابراین باید با دقت انتخاب شوند.

---

پیکربندی‌های لازم برای هماهنگی بین اجزای مختلف در لینوکس

برای پیاده‌سازی هماهنگی صحیح بین اجزای مختلف در یک کلاستر HA در سیستم لینوکس، باید چندین پیکربندی انجام شود. در اینجا به برخی از مراحل و تنظیمات مهم اشاره می‌کنیم:

1. پیکربندی Corosync برای ارتباطات گره‌ها:

فایل پیکربندی Corosync معمولاً در مسیر /etc/corosync/corosync.conf قرار دارد. برای برقراری ارتباط صحیح بین گره‌ها، باید تنظیمات مربوط به bindnetaddr و mcastaddr در این فایل تنظیم شود.

totem {
  version: 2
  config_version: 2
  token: 5000
  token_retransmits_before_loss_const: 10
  clear_node_high_bit: yes
  interface {
    ringnumber: 0
    bindnetaddr: 192.168.1.0
    mcastaddr: 226.94.1.1
    mcastport: 5405
  }
}

2. پیکربندی Pacemaker برای مدیریت منابع:

برای مدیریت منابع و تنظیم failover به‌صورت خودکار، از ابزار Pacemaker استفاده می‌شود. برای اضافه کردن یک سرویس مانند Apache به کلاستر، باید از دستور زیر استفاده کرد:

sudo crm configure primitive WebServer ocf:heartbeat:apache op monitor interval=30s

3. پیکربندی DRBD برای همگام‌سازی داده‌ها:

برای همگام‌سازی داده‌ها بین گره‌ها، باید از DRBD استفاده کرد. این ابزار به‌طور خودکار داده‌ها را بین گره‌های اصلی و پشتیبان همگام می‌کند. فایل پیکربندی DRBD معمولاً در مسیر /etc/drbd.conf قرار دارد.

resource r0 {
  on node1 {
    device /dev/drbd0;
    disk /dev/sdb1;
    address 192.168.1.1:7789;
  }
  on node2 {
    device /dev/drbd0;
    disk /dev/sdb1;
    address 192.168.1.2:7789;
  }
}

---

جمع‌بندی

پیاده‌سازی HA در سیستم‌های لینوکس نیازمند هماهنگی دقیق بین اجزای مختلف مانند منابع ذخیره‌سازی، گره‌ها، ارتباطات شبکه و مدیریت منابع است. این هماهنگی برای اطمینان از انتقال صحیح داده‌ها، زمان‌بندی مناسب برای failover، و در دسترس‌پذیری مداوم سرویس‌ها ضروری است. ابزارهایی مانند Corosync، Pacemaker، و DRBD نقش کلیدی در این هماهنگی دارند و باید به‌درستی پیکربندی شوند تا از یکپارچگی و پایداری کلاستر اطمینان حاصل شود.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تأثیرات شبکه و ذخیره‌سازی بر روی HA” subtitle=”توضیحات کامل”]برای پیاده‌سازی یک سیستم High Availability (HA) مؤثر، توجه به تأثیرات شبکه و ذخیره‌سازی حیاتی است. این دو جزء می‌توانند به‌طور مستقیم در عملکرد، پایداری و دسترسی مداوم به سرویس‌ها تأثیر بگذارند. در این بخش، به‌طور جامع به تأثیرات شبکه و ذخیره‌سازی بر روی HA خواهیم پرداخت و اهمیت پیکربندی صحیح آن‌ها را بررسی می‌کنیم.

تأثیرات شبکه بر روی HA

شبکه یکی از ارکان اصلی در فراهم آوردن HA است، زیرا گره‌ها باید بتوانند به‌طور پیوسته با هم ارتباط برقرار کنند تا هماهنگی و انتقال منابع به‌درستی انجام شود. هرگونه مشکل در شبکه می‌تواند منجر به قطعی سرویس‌ها یا تأخیر در فرآیند failover شود.

چالش‌ها و تأثیرات شبکه بر HA عبارتند از:

1. زمان تأخیر شبکه (Latency): تأخیر بالای شبکه می‌تواند باعث افزایش زمان شناسایی خرابی‌ها و جابجایی منابع شود. در صورت بروز خرابی در یک گره، اگر شبکه دارای تأخیر بالا باشد، فرایند انتقال منابع به گره دیگر ممکن است با تاخیر مواجه شود، که می‌تواند باعث قطعی سرویس‌ها شود.
   • راه‌حل‌ها: برای کاهش تأخیر شبکه، باید از شبکه‌های با سرعت بالا و تأخیر پایین استفاده شود و همچنین به تنظیمات MTU (Maximum Transmission Unit) و Jumbo Frames دقت شود.
2. اتصال شبکه و قطع‌بودن ارتباطات: در صورتی که شبکه میان گره‌ها قطع شود، ارتباط میان گره‌ها دچار اختلال شده و هماهنگی میان منابع تحت تأثیر قرار می‌گیرد. اگر اتصال شبکه قطع شود، حتی اگر گره‌ها به‌طور صحیح پیکربندی شده باشند، امکان failover صحیح و انتقال منابع وجود نخواهد داشت.
   • راه‌حل‌ها: استفاده از فناوری‌هایی مانند Heartbeat و Corosync می‌تواند به بهبود ارتباطات و اطمینان از دسترسی مداوم به منابع کمک کند.
3. امنیت شبکه: حملات شبکه مانند Denial of Service (DoS) می‌تواند باعث مختل شدن ارتباطات میان گره‌ها و تأثیر منفی بر روی HA شود. بنابراین، تنظیمات امنیتی شبکه باید به‌گونه‌ای باشد که از حملات جلوگیری کند.
   • راه‌حل‌ها: استفاده از فایروال‌های سخت‌افزاری و نرم‌افزاری و همچنین پیکربندی مناسب IPSec یا VPN برای محافظت از داده‌ها و ارتباطات میان گره‌ها ضروری است.
4. شبکه‌های چندگانه و Load Balancing: در یک کلاستر HA، معمولاً از شبکه‌های چندگانه برای توزیع بار و ایجاد پایداری بیشتر استفاده می‌شود. این امر می‌تواند کمک کند تا در صورت بروز مشکل در یکی از شبکه‌ها، شبکه دیگری جایگزین آن شود.
   • راه‌حل‌ها: استفاده از load balancers مانند HAProxy یا Nginx می‌تواند کمک کند تا بار شبکه بین گره‌ها به‌طور یکنواخت تقسیم شود.

تأثیرات ذخیره‌سازی بر روی HA

ذخیره‌سازی یکی از اجزای حیاتی در سیستم‌های HA است، زیرا داده‌ها باید به‌طور مداوم و همگام در دسترس باشند. اگر داده‌ها در صورت خرابی گره از دست بروند یا به‌درستی به گره‌های دیگر منتقل نشوند، در دسترس‌پذیری سرویس‌ها و اطلاعات دچار مشکل خواهد شد.

چالش‌ها و تأثیرات ذخیره‌سازی بر HA عبارتند از:

1. همگام‌سازی داده‌ها (Data Synchronization): در سیستم‌های HA، داده‌ها باید به‌طور همزمان بین گره‌ها همگام شوند تا هر گره جدیدی که جایگزین گره خراب شده می‌شود، داده‌های کامل و به‌روز را داشته باشد. هرگونه اشکال در همگام‌سازی می‌تواند باعث از دست رفتن داده‌ها یا دسترسی نداشتن به اطلاعات به‌روز شود.
   • راه‌حل‌ها: استفاده از DRBD (Distributed Replicated Block Device) و GlusterFS به‌عنوان ابزارهای همگام‌سازی داده‌ها می‌تواند کمک کند تا داده‌ها بین گره‌ها به‌طور مداوم همگام شوند.
2. مقیاس‌پذیری ذخیره‌سازی: سیستم‌های HA به‌ویژه در محیط‌هایی که نیاز به پردازش داده‌های زیاد دارند، باید قادر به مقیاس‌پذیری باشند. نیاز به ظرفیت ذخیره‌سازی بالا در صورت گسترش سیستم و افزایش حجم داده‌ها یکی از چالش‌های رایج است.
   • راه‌حل‌ها: استفاده از ذخیره‌سازی توزیع‌شده مانند Ceph یا GlusterFS که می‌توانند به‌طور پویا مقیاس‌پذیری ذخیره‌سازی را انجام دهند، یک گزینه مناسب است.
3. فراوانی و Redundancy داده‌ها: برای اطمینان از در دسترس بودن داده‌ها، باید نسخه‌های اضافی از داده‌ها در گره‌های مختلف ذخیره شوند. در صورت بروز خرابی در یک گره، نسخه‌های دیگری از داده‌ها باید در گره‌های دیگر در دسترس باشند.
   • راه‌حل‌ها: استفاده از تکنیک‌های RAID، LVM (Logical Volume Manager)، و ZFS می‌تواند برای ایجاد redundancy و حفظ در دسترس‌پذیری داده‌ها مفید باشد.
4. بازسازی داده‌ها و بازیابی در برابر خرابی: در صورت بروز خرابی در ذخیره‌سازی، فرآیند بازیابی داده‌ها باید به‌طور سریع و کارآمد انجام شود. در صورت استفاده از فناوری‌های ذخیره‌سازی مشابه RAID یا ZFS, این فرآیند می‌تواند زمان‌بر باشد.
   • راه‌حل‌ها: استفاده از backup و snapshots به‌طور منظم می‌تواند در بازیابی سریع‌تر داده‌ها در صورت خرابی کمک کند.

---

پیکربندی‌های لازم برای شبکه و ذخیره‌سازی در HA

برای پیاده‌سازی HA در سیستم‌های لینوکس، باید پیکربندی‌هایی برای شبکه و ذخیره‌سازی انجام شود. در اینجا به برخی از تنظیمات و پیکربندی‌های مهم اشاره می‌کنیم:

1. پیکربندی شبکه با Corosync و Pacemaker:فایل پیکربندی Corosync معمولاً در مسیر /etc/corosync/corosync.conf قرار دارد. این فایل باید برای اطمینان از ارتباط درست میان گره‌ها پیکربندی شود.

   totem {
     version: 2
     config_version: 2
     token: 5000
     token_retransmits_before_loss_const: 10
     clear_node_high_bit: yes
     interface {
       ringnumber: 0
       bindnetaddr: 192.168.1.0
       mcastaddr: 226.94.1.1
       mcastport: 5405
     }
   }
   

2. پیکربندی DRBD برای همگام‌سازی داده‌ها:فایل پیکربندی DRBD معمولاً در مسیر /etc/drbd.conf قرار دارد و برای همگام‌سازی داده‌ها باید پیکربندی شود.

   resource r0 {
     on node1 {
       device /dev/drbd0;
       disk /dev/sdb1;
       address 192.168.1.1:7789;
     }
     on node2 {
       device /dev/drbd0;
       disk /dev/sdb1;
       address 192.168.1.2:7789;
     }
   }
   

3. پیکربندی RAID برای ذخیره‌سازی با افزونگی:استفاده از RAID 1 برای ذخیره‌سازی افزونه می‌تواند به‌عنوان یک راه‌حل برای افزونگی داده‌ها و جلوگیری از از دست رفتن اطلاعات در صورت خرابی هارد دیسک مفید باشد.

   sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda /dev/sdb
   

---

جمع‌بندی

شبکه و ذخیره‌سازی در سیستم‌های HA نقش حیاتی در اطمینان از در دسترس‌پذیری مداوم و بدون قطعی سرویس‌ها دارند. تأخیر شبکه، قطع ارتباطات، امنیت شبکه، همگام‌سازی داده‌ها و مقیاس‌پذیری ذخیره‌سازی از جمله چالش‌هایی هستند که باید در پیاده‌سازی HA در نظر گرفته شوند. استفاده از ابزارهایی مانند Corosync، Pacemaker، DRBD، GlusterFS و RAID به بهبود عملکرد و مقیاس‌پذیری سیستم‌های HA کمک می‌کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مشکلات مربوط به همگام‌سازی داده‌ها و مدیریت منابع در HA” subtitle=”توضیحات کامل”]در سیستم‌های High Availability (HA)، همگام‌سازی داده‌ها و مدیریت منابع از اجزای کلیدی برای تضمین در دسترس‌پذیری و یکپارچگی سیستم هستند. هرگونه مشکل در این دو بخش می‌تواند منجر به خرابی سرویس‌ها، از دست رفتن داده‌ها یا افزایش زمان downtime شود. در این بخش، به مشکلاتی که ممکن است در هنگام همگام‌سازی داده‌ها و مدیریت منابع رخ دهد، پرداخته و راه‌حل‌هایی برای مقابله با این مشکلات ارائه می‌دهیم.

مشکلات همگام‌سازی داده‌ها

1. تأخیر در همگام‌سازی (Sync Delay): یکی از مشکلات رایج در سیستم‌های HA، تأخیر در همگام‌سازی داده‌ها میان گره‌ها است. این تأخیر ممکن است به دلیل محدودیت‌های شبکه، سرعت پایین ذخیره‌سازی یا منابع سخت‌افزاری موجود رخ دهد. در نتیجه، داده‌های به‌روز در گره‌های دیگر قابل دسترسی نخواهند بود تا زمانی که فرایند همگام‌سازی به‌طور کامل انجام شود.راه‌حل‌ها:
   • استفاده از شبکه‌های سریع و با تأخیر پایین.
   • بهینه‌سازی پیکربندی ذخیره‌سازی و استفاده از فناوری‌های ذخیره‌سازی سریع‌تر مانند SSD.
   • استفاده از DRBD (Distributed Replicated Block Device) یا Ceph برای همگام‌سازی داده‌ها در مقیاس بزرگ.
2. تضاد داده‌ها (Data Conflicts): در برخی موارد، اگر دو یا چند گره تغییرات هم‌زمانی را در داده‌ها اعمال کنند، تضاد داده‌ها ممکن است به وجود آید. این مشکل به‌ویژه در گره‌های Active-Active که به‌طور هم‌زمان به یک منبع دسترسی دارند، شایع است.راه‌حل‌ها:
   • استفاده از Quorum برای اطمینان از اینکه تنها یک گره تغییرات داده‌ها را اعمال می‌کند.
   • استفاده از Conflict Resolution Policies برای حل خودکار تضاد داده‌ها.
   • استفاده از سیستم‌های Version Control برای مدیریت نسخه‌های مختلف داده‌ها و جلوگیری از تضاد.
3. از دست رفتن داده‌ها در صورت خرابی گره (Data Loss During Node Failure): در صورتی که یک گره در حین عملیات همگام‌سازی خراب شود، ممکن است برخی از تغییرات داده‌ها از دست بروند. این مشکل به‌ویژه در پیاده‌سازی‌های Active-Passive یا کلاسترهایی که داده‌ها را به‌صورت غیر همزمان همگام‌سازی می‌کنند، شایع است.راه‌حل‌ها:
   • استفاده از فناوری‌هایی مانند Synchronous Replication که اطمینان حاصل می‌کند داده‌ها به‌طور همزمان در گره‌ها همگام شوند.
   • برنامه‌ریزی دقیق و منظم برای Backup داده‌ها و استفاده از Snapshots برای کاهش خطر از دست دادن داده‌ها.
4. همگام‌سازی ناقص پس از Failover: در صورتی که failover در حین فرایند همگام‌سازی رخ دهد، ممکن است گره جدید داده‌های ناقص یا قدیمی را دریافت کند. این موضوع می‌تواند باعث ایجاد یک وضعیت ناسازگار شود.راه‌حل‌ها:
   • اطمینان از Consistency Checks بعد از هر failover برای تضمین یکپارچگی داده‌ها.
   • استفاده از ابزارهایی مانند Pacemaker و Corosync برای مدیریت دقیق فرایند failover و همگام‌سازی.

مشکلات مدیریت منابع در HA

1. تنظیمات نادرست منابع (Incorrect Resource Configurations): در سیستم‌های HA، مدیریت منابع (مانند پردازنده، حافظه، و ذخیره‌سازی) باید به‌طور دقیق انجام شود. اگر منابع به‌طور صحیح پیکربندی نشوند، ممکن است برخی از گره‌ها نتوانند از منابع به درستی استفاده کنند که می‌تواند منجر به کاهش کارایی یا خرابی گره‌ها شود.راه‌حل‌ها:
   • استفاده از ابزارهایی مانند Pacemaker برای مدیریت منابع و اطمینان از تخصیص منابع به‌طور صحیح.
   • پیکربندی دقیق Resource Agents برای مدیریت منابع به‌طور خودکار.
   • اعمال سیاست‌های Failover برای منابع حساس، به‌ویژه در سیستم‌های Active-Active.
2. آسیب‌پذیری در تخصیص منابع در زمان شکست (Resource Allocation Vulnerabilities During Failure): وقتی که یک گره خراب می‌شود و failover انجام می‌شود، منابع باید به گره جدید منتقل شوند. در صورت بروز خطا در فرایند تخصیص منابع، ممکن است گره جدید نتواند به‌طور کامل از منابع موجود استفاده کند.راه‌حل‌ها:
   • اطمینان از پیکربندی Resource Migration برای تخصیص منابع به‌طور دینامیک.
   • استفاده از سیستم‌های Load Balancing برای توزیع منابع بین گره‌ها به‌طور یکنواخت.
3. عدم استفاده بهینه از منابع (Underutilization of Resources): در سیستم‌های HA، منابع ممکن است به‌طور نابرابر بین گره‌ها تقسیم شوند. این امر می‌تواند منجر به Underutilization برخی از گره‌ها و Overutilization سایر گره‌ها شود که در نهایت به کاهش کارایی کلی سیستم منجر می‌شود.راه‌حل‌ها:
   • استفاده از Auto-scaling برای توزیع منابع به‌طور خودکار بین گره‌ها.
   • پیکربندی Load Balancer برای توزیع بار به‌طور بهینه و جلوگیری از استفاده نادرست از منابع.
4. کمبود منابع در زمان اوج بار (Resource Exhaustion During Peak Load): در زمان‌هایی که ترافیک زیاد است یا بار پردازشی بالا می‌رود، ممکن است منابع به‌طور کافی در دسترس نباشند و این باعث بروز مشکلاتی در عملکرد HA شود.راه‌حل‌ها:
   • استفاده از Scaling Policies برای افزایش منابع در زمان اوج بار.
   • طراحی سیستم با استفاده از Horizontal Scaling برای اضافه کردن گره‌های جدید به کلاستر در مواقع نیاز.
5. نبود مکانیزم‌های بازگشت به وضعیت اولیه (Lack of Rollback Mechanisms): در صورتی که مشکلی در همگام‌سازی یا تخصیص منابع پیش آید، نبود مکانیسم‌های Rollback برای بازگشت به وضعیت پایدار قبلی می‌تواند موجب افزایش downtime و قطعی سرویس‌ها شود.راه‌حل‌ها:
   • استفاده از Transaction Logs برای ثبت تغییرات و امکان بازگشت به وضعیت قبلی.
   • ایجاد و استفاده از Backup‌های مداوم و بازیابی سریع آن‌ها در صورت بروز مشکل.

---

پیکربندی‌ها و ابزارهای مفید برای مدیریت منابع و همگام‌سازی داده‌ها

1. پیکربندی Pacemaker برای مدیریت منابع:در اینجا نحوه پیکربندی یک منبع برای HA با استفاده از Pacemaker آورده شده است. فایل پیکربندی معمولا در مسیر /etc/pacemaker/pacemaker.conf قرار دارد.

   crm configure primitive my_resource ocf:heartbeat:IPaddr2 \
       params ip=192.168.1.100 cidr_netmask=24 \
       op monitor interval=30s
   

2. پیکربندی DRBD برای همگام‌سازی داده‌ها:پیکربندی DRBD برای همگام‌سازی داده‌ها در سیستم‌های HA به این صورت است:

   resource r0 {
     on node1 {
       device /dev/drbd0;
       disk /dev/sdb1;
       address 192.168.1.1:7789;
     }
     on node2 {
       device /dev/drbd0;
       disk /dev/sdb1;
       address 192.168.1.2:7789;
     }
   }
   

3. پیکربندی Auto-scaling برای منابع:برای استفاده از Auto-scaling در محیط‌های HA می‌توانید از ابزارهای AWS Auto Scaling یا Kubernetes Horizontal Pod Autoscaler برای مقیاس‌دهی منابع به‌طور خودکار استفاده کنید.

---

جمع‌بندی

همگام‌سازی داده‌ها و مدیریت منابع در سیستم‌های High Availability از اهمیت بالایی برخوردار است و مشکلاتی مانند تأخیر در همگام‌سازی، تضاد داده‌ها، تخصیص نادرست منابع و کمبود منابع می‌تواند تأثیر زیادی بر عملکرد سیستم بگذارد. استفاده از ابزارهایی مانند Pacemaker، DRBD، و Auto-scaling می‌تواند به بهبود عملکرد و اطمینان از در دسترس‌پذیری دائمی سیستم کمک کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”چالش‌های پیکربندی و عیب‌یابی در کلاسترهای لینوکس” subtitle=”توضیحات کامل”]پیاده‌سازی کلاسترهای High Availability (HA) در لینوکس می‌تواند چالش‌های زیادی به همراه داشته باشد. از پیکربندی صحیح اجزای مختلف کلاستر گرفته تا مشکلات در شناسایی و رفع ایرادات، همگی از عواملی هستند که ممکن است بر کارکرد سیستم‌های HA تأثیر بگذارند. در این بخش به چالش‌های رایج در پیکربندی و عیب‌یابی کلاسترهای لینوکس می‌پردازیم و راهکارهایی برای حل آن‌ها ارائه می‌دهیم.

چالش‌های پیکربندی در کلاسترهای لینوکس

1. تنظیمات نادرست شبکه یکی از چالش‌های اصلی در پیکربندی کلاسترهای لینوکس، تنظیمات نادرست شبکه است. کلاسترهای HA به شدت به شبکه‌های سریع و پایدار وابسته هستند، و مشکلاتی مانند latency بالا، پهنای باند ناکافی، یا پیکربندی نادرست کارت‌های شبکه می‌تواند عملکرد کلاستر را تحت تأثیر قرار دهد.راه‌حل‌ها:
   • بررسی و بهینه‌سازی تنظیمات شبکه مانند bonding و VLAN برای اطمینان از ارتباط پایدار میان گره‌ها.
   • استفاده از ابزارهایی مانند ping و traceroute برای شبیه‌سازی ارتباطات شبکه‌ای و شناسایی مشکلات شبکه‌ای.

   مثال تنظیمات کارت شبکه:

   nmcli con add type bond con-name bond0 ifname bond0 mode 802.3ad miimon 100 updelay 200 downdelay 200
   nmcli con add type ethernet con-name slave-eth0 ifname eth0 master bond0
   nmcli con add type ethernet con-name slave-eth1 ifname eth1 master bond0
   

2. نادرست بودن تنظیمات سرویس‌های HA برای اطمینان از عملکرد صحیح کلاستر، باید تنظیمات سرویس‌های HA مانند Pacemaker، Corosync، و DRBD به‌درستی انجام شود. یک اشتباه کوچک در تنظیمات می‌تواند منجر به مشکلاتی مانند Failover نادرست یا عدم شناسایی منابع شود.راه‌حل‌ها:
   • استفاده از دستور crm configure show برای بررسی وضعیت پیکربندی سرویس‌های HA.
   • بررسی و اصلاح فایل‌های پیکربندی سرویس‌ها در مسیرهای /etc/pacemaker/pacemaker.conf و /etc/corosync/corosync.conf.

   مثال پیکربندی Pacemaker:

   crm configure primitive my_ip ocf:heartbeat:IPaddr2 \
       params ip=192.168.1.100 cidr_netmask=24 \
       op monitor interval=30s
   

3. نقص در پیکربندی منابع و منابع مشترک در بسیاری از مواقع، منابعی مانند IPهای مجازی، پایگاه‌های داده یا سیستم‌های ذخیره‌سازی به اشتباه یا به‌طور ناقص پیکربندی می‌شوند که می‌تواند منجر به بروز مشکلاتی در دسترسی به منابع مشترک شود.راه‌حل‌ها:
   • بررسی دقیق و انجام تست‌های مانیتورینگ برای اطمینان از در دسترس بودن منابع مشترک.
   • استفاده از Heartbeat برای اطمینان از اینکه منابع به درستی بین گره‌ها توزیع شده است.
4. هماهنگی نادرست زمان در بسیاری از موارد، اگر زمان گره‌ها در کلاستر هماهنگ نباشد، مشکلاتی مانند اختلاف در زمان‌های Failover و مشکلات همگام‌سازی داده‌ها ایجاد می‌شود. این مشکل معمولاً در زمان‌هایی که از NTP برای همگام‌سازی زمان استفاده می‌شود، رخ می‌دهد.راه‌حل‌ها:
   • اطمینان از همگام بودن زمان بین تمام گره‌ها با استفاده از NTP.
   • استفاده از دستورات زیر برای نصب و پیکربندی NTP:

   yum install ntp
   systemctl start ntpd
   systemctl enable ntpd
   

5. مدیریت و پیکربندی ذخیره‌سازی مشترک استفاده از سیستم‌های ذخیره‌سازی مشترک برای به اشتراک‌گذاری داده‌ها بین گره‌ها، مانند SAN یا NAS، ممکن است مشکلاتی به همراه داشته باشد. مشکلاتی مانند عدم همگام‌سازی داده‌ها یا اتصال گره‌ها به ذخیره‌سازی مشترک به‌طور موقت قطع شود.راه‌حل‌ها:
   • پیکربندی دقیق سیستم‌های ذخیره‌سازی مشترک و اطمینان از دسترسی گره‌ها به این سیستم‌ها.
   • استفاده از DRBD (Distributed Replicated Block Device) یا Ceph برای همگام‌سازی داده‌ها بین گره‌ها.

چالش‌های عیب‌یابی در کلاسترهای لینوکس

1. تشخیص دقیق خطاهای ارتباطی یکی از بزرگترین چالش‌ها در عیب‌یابی کلاسترها، تشخیص و شناسایی دقیق خطاهای ارتباطی است. ارتباطات میان گره‌ها ممکن است به دلایل مختلف قطع شوند و این مشکل می‌تواند منجر به failover نادرست یا در دسترس نبودن سرویس‌ها شود.راه‌حل‌ها:
   • استفاده از ابزارهای عیب‌یابی شبکه مانند tcpdump، netstat، و ss برای بررسی وضعیت ارتباطات بین گره‌ها.
   • بررسی فایل‌های لاگ سیستم در مسیر /var/log/messages و /var/log/syslog برای شناسایی مشکلات احتمالی.

   مثال استفاده از tcpdump:

   tcpdump -i eth0 -nn host 192.168.1.100
   

2. عدم توانایی شناسایی منابع خراب در صورتی که یکی از منابع گره خراب شود، ممکن است سیستم قادر به شناسایی آن نباشد و این مشکل باعث Failover نادرست یا عدم پاسخگویی سیستم شود.راه‌حل‌ها:
   • بررسی و استفاده از دستور crm resource status برای مشاهده وضعیت منابع و اطمینان از عملکرد صحیح آن‌ها.
   • استفاده از Pacemaker برای پیکربندی Failure Detection به‌طور خودکار.

   مثال بررسی وضعیت منابع با crm:

   crm resource status
   

3. خطا در تنظیمات Failover مشکلات در تنظیمات Failover می‌تواند منجر به خرابی در انتقال منابع یا عدم تأمین دسترسی سریع به سرویس‌ها شود. این موضوع می‌تواند بر کارایی و پایداری کلاستر تأثیر زیادی بگذارد.راه‌حل‌ها:
   • بررسی و پیکربندی درست resource constraints در Pacemaker برای تنظیمات Failover صحیح.
   • استفاده از crm configure show برای مشاهده تنظیمات کنونی Failover.
4. تشخیص مشکلات سیستم ذخیره‌سازی مشکلات در سیستم‌های ذخیره‌سازی مانند SAN یا NAS می‌تواند منجر به اختلال در دسترسی به داده‌ها و مشکلاتی در همگام‌سازی اطلاعات شود.راه‌حل‌ها:
   • استفاده از دستورات مانیتورینگ مانند lsblk، df، و iostat برای نظارت بر وضعیت سیستم ذخیره‌سازی.
   • بررسی لاگ‌های مربوط به ذخیره‌سازی در مسیر /var/log/messages برای شناسایی خطاهای احتمالی.
5. بررسی لاگ‌ها و پیام‌های خطا در عیب‌یابی کلاستر، بررسی لاگ‌ها و پیام‌های خطا می‌تواند اطلاعات مهمی درباره علت بروز مشکل فراهم کند.راه‌حل‌ها:
   • بررسی فایل‌های لاگ در مسیرهای مختلف مانند /var/log/pacemaker/ و /var/log/corosync/ برای شناسایی مشکلات دقیق.
   • استفاده از journalctl برای مشاهده پیام‌های سیستمی در سیستم‌های مدرن لینوکس.

   مثال بررسی لاگ‌ها با journalctl:

   journalctl -u pacemaker
   

جمع‌بندی

پیکربندی و عیب‌یابی کلاسترهای لینوکس می‌تواند پیچیدگی‌های زیادی داشته باشد. مشکلات شبکه، منابع مشترک، تنظیمات سرویس‌های HA، و مشکلات ذخیره‌سازی از جمله چالش‌های رایج در این زمینه هستند. با استفاده از ابزارهای مانیتورینگ و عیب‌یابی مانند crm, tcpdump, و journalctl، می‌توان مشکلات را شناسایی و برطرف کرد. همچنین، پیکربندی دقیق سرویس‌های HA مانند Pacemaker، Corosync، و DRBD برای بهبود عملکرد و کاهش خطاها بسیار مهم است.[/cdb_course_lesson][cdb_course_lesson title=”فصل 9. مزایا و معایب استفاده از High Availability و Clustering”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مزایای HA: کاهش زمان خرابی، بهبود عملکرد، افزایش اعتماد به سیستم” subtitle=”توضیحات کامل”]پیاده‌سازی High Availability (HA) یا دسترسی‌پذیری بالا، یک استراتژی اساسی در طراحی و مدیریت سیستم‌های شبکه و سرورها است که باعث افزایش پایداری و کارایی سیستم می‌شود. این استراتژی از اجزای مختلفی مانند کلاسترها، مکانیزم‌های Failover، و مدیریت منابع استفاده می‌کند تا از زمان خرابی سیستم‌ها جلوگیری کرده و اعتماد به سیستم را افزایش دهد. در این بخش، به مزایای اصلی HA خواهیم پرداخت:

1. کاهش زمان خرابی

یکی از بزرگ‌ترین مزایای HA کاهش زمان خرابی سیستم‌ها است. در سیستم‌هایی که از HA استفاده می‌کنند، زمان خرابی به شدت کاهش می‌یابد زیرا هرگونه خرابی در یک گره یا سرور می‌تواند به سرعت به گره یا سرور دیگری منتقل شود. این فرآیند معمولاً از طریق Failover و Replication انجام می‌شود. مکانیزم Failover به‌طور خودکار از گره‌ای که به دلیل خرابی از دست رفته، به گره دیگری که آماده به کار است منتقل می‌شود.

راه‌حل‌ها و مکانیزم‌ها:

• Failover: این مکانیزم به‌طور خودکار عملیات سیستم را از یک گره به گره دیگری منتقل می‌کند.
• Replication: داده‌ها به صورت همزمان و به‌طور مداوم در چندین گره کلاستر همگام‌سازی می‌شوند، بنابراین در صورت بروز خرابی، داده‌ها از بین نمی‌روند.

مثال تنظیم Failover در Pacemaker:

crm configure primitive my_virtual_ip ocf:heartbeat:IPaddr2 \
    params ip=192.168.1.100 cidr_netmask=24 \
    op monitor interval=30s

در این مثال، در صورت خرابی گره، آدرس IP به گره دیگر منتقل می‌شود تا دسترسی به سیستم بدون وقفه ادامه یابد.

2. بهبود عملکرد

یکی دیگر از مزایای بزرگ HA، بهبود عملکرد سیستم است. این به این دلیل است که در اکثر سیستم‌های HA، از Load Balancing استفاده می‌شود که بار درخواست‌ها را بین چندین گره تقسیم می‌کند. با این تقسیم‌بندی، سیستم می‌تواند به طور موثرتری به درخواست‌ها پاسخ دهد و منابع را بهتر مدیریت کند. از طرف دیگر، گره‌های اضافی می‌توانند برای پشتیبانی از بار اضافی و در دسترس‌بودن بیشتر منابع به سیستم اضافه شوند.

راه‌حل‌ها و مکانیزم‌ها:

• Load Balancing: بار درخواست‌ها میان گره‌ها تقسیم می‌شود، که باعث افزایش عملکرد و کاهش فشار روی هر گره می‌شود.
• Scalability: می‌توان با افزودن گره‌های بیشتر، مقیاس سیستم را افزایش داد و از این طریق عملکرد سیستم را تقویت کرد.

مثال استفاده از Load Balancer: در بسیاری از محیط‌های HA، برای توزیع بار بین گره‌ها از ابزارهایی مانند HAProxy یا Nginx استفاده می‌شود.

server 192.168.1.101 maxconn 32
server 192.168.1.102 maxconn 32

این دستور بار درخواست‌ها را بین دو سرور (با IPهای مشخص‌شده) توزیع می‌کند تا عملکرد سیستم بهینه شود.

3. افزایش اعتماد به سیستم

با استفاده از HA، سیستم‌ها از پایداری و اطمینان بیشتری برخوردار می‌شوند که این امر باعث افزایش اعتماد به سیستم از سوی کاربران و مشتریان می‌شود. در سیستم‌های معمولی، خرابی یا از دست رفتن دسترسی به خدمات می‌تواند موجب ایجاد اختلالات گسترده شود. اما با HA، حتی در صورت بروز خرابی، سیستم به سرعت بازسازی می‌شود و خدمات به کاربران ادامه می‌یابد، بدون اینکه تأثیر زیادی بر روی آن‌ها داشته باشد.

راه‌حل‌ها و مکانیزم‌ها:

• Redundancy: با تکرار منابع و گره‌ها، اطمینان حاصل می‌شود که همیشه یک نسخه از منابع در دسترس است.
• Automatic Failover: به‌طور خودکار عملیات به گره سالم منتقل می‌شود و هیچ‌گاه خدمات از دست نمی‌رود.

مثال فعال‌سازی Redundancy در ذخیره‌سازی با استفاده از DRBD: در اینجا، از DRBD برای اطمینان از تکرار داده‌ها استفاده می‌شود.

drbdadm create-md r0
drbdadm up r0

این دستور ذخیره‌سازی داده‌ها را بین دو گره تکرار می‌کند و باعث افزایش در دسترس‌بودن و اعتماد به سیستم می‌شود.

جمع‌بندی

پیاده‌سازی HA در سیستم‌های لینوکسی باعث می‌شود که سیستم‌ها از مزایای زیادی برخوردار شوند:

• کاهش زمان خرابی: در صورت بروز خرابی در یک گره، سیستم به‌طور خودکار به گره دیگری منتقل می‌شود.
• بهبود عملکرد: با استفاده از Load Balancing، بار میان گره‌ها تقسیم می‌شود و عملکرد سیستم افزایش می‌یابد.
• افزایش اعتماد به سیستم: به دلیل Redundancy و Failover، سیستم از پایداری بیشتری برخوردار است و به این ترتیب اعتماد کاربران و مشتریان افزایش می‌یابد.

با تنظیم دقیق و استفاده از ابزارهای مناسب، می‌توان از این مزایا به‌طور مؤثر در کلاسترهای HA بهره‌برداری کرد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”معایب HA: پیچیدگی پیکربندی، هزینه‌های اضافی، نیاز به منابع سخت‌افزاری بالا” subtitle=”توضیحات کامل”]در کنار مزایای چشمگیر High Availability (HA) که به‌طور قابل توجهی به کاهش زمان خرابی، افزایش عملکرد و اطمینان از دسترسی مداوم به سرویس‌ها کمک می‌کند، این فناوری همچنین معایبی دارد که باید در هنگام پیاده‌سازی در نظر گرفته شود. در این بخش، به معایب اصلی HA و چالش‌هایی که ممکن است در فرآیند پیاده‌سازی با آن‌ها روبه‌رو شویم، پرداخته خواهد شد.

1. پیچیدگی پیکربندی

پیاده‌سازی یک سیستم HA معمولاً نیازمند پیکربندی‌های پیچیده و تخصصی است. در سیستم‌های HA، لازم است که چندین گره یا سرور به‌طور همزمان با هم هماهنگ شوند تا تضمین کنند که در صورت خرابی، خدمات به‌طور مداوم ادامه یابد. این هماهنگی بین گره‌ها و اجزای مختلف سیستم (مثل Failover, Replication, Load Balancing) می‌تواند باعث پیچیدگی در پیکربندی شود.

چالش‌ها:

• هماهنگی و پیکربندی صحیح گره‌ها.
• تنظیم دقیق مکانیزم‌های Failover و Failback.
• همگام‌سازی داده‌ها در محیط‌های پیچیده.

راه‌حل‌ها:

برای کاهش پیچیدگی پیکربندی، استفاده از ابزارهای مدیریت کلاستر و مستندات دقیق ضروری است. در اینجا به تنظیم Pacemaker برای پیکربندی HA اشاره خواهیم کرد.

مثال پیکربندی Failover با Pacemaker:

crm configure primitive web_server ocf:heartbeat:apache \
    params configfile="/etc/httpd/conf/httpd.conf" \
    op monitor interval=30s

این دستور، Apache را به‌عنوان یک سرویس HA پیکربندی می‌کند. اگر گره‌ای که Apache روی آن اجرا می‌شود دچار خرابی شود، فرآیند Failover به گره دیگر منتقل می‌شود.

2. هزینه‌های اضافی

پیاده‌سازی HA نیازمند منابع اضافی برای انجام عملیات‌های همزمان است که به معنای افزایش هزینه‌ها می‌باشد. این هزینه‌ها در بخش‌های مختلفی ظاهر می‌شوند:

• هزینه‌های سخت‌افزاری: برای داشتن گره‌های پشتیبان، نیاز به سرورهای اضافی، فضای ذخیره‌سازی و تجهیزات شبکه دارید.
• هزینه‌های نرم‌افزاری: بسیاری از ابزارهای HA ممکن است نیاز به مجوزهای نرم‌افزاری اضافی داشته باشند.
• هزینه‌های نیروی انسانی: پیاده‌سازی و مدیریت یک سیستم HA به دانش تخصصی نیاز دارد که معمولاً نیاز به متخصصان باتجربه در این زمینه دارد.

چالش‌ها:

• هزینه اضافی برای سخت‌افزارهای اضافه (مثل سرورها و ذخیره‌سازی).
• نیاز به تیم‌های فنی برای پشتیبانی و نگهداری.
• نیاز به نرم‌افزارهای خاص و لایسنس‌های اضافی.

راه‌حل‌ها:

برای کاهش هزینه‌ها، باید نیازمندی‌های واقعی سیستم به‌دقت ارزیابی شود و در صورت امکان از منابع موجود به بهترین نحو استفاده شود. علاوه بر این، می‌توان از Cloud Services برای کاهش هزینه‌های سخت‌افزاری و بهره‌مندی از قابلیت‌های HA به‌صورت مقیاس‌پذیر استفاده کرد.

مثال استفاده از سرویس‌های ابری برای HA: در سرویس‌های ابری مانند AWS، می‌توان از Elastic Load Balancer (ELB) و Auto Scaling برای مدیریت بار و پشتیبان‌گیری استفاده کرد، که نیاز به سخت‌افزار اضافی را کاهش می‌دهد.

aws elb create-load-balancer \
    --load-balancer-name my-ha-load-balancer \
    --listeners "Protocol=HTTP,LoadBalancerPort=80,InstanceProtocol=HTTP,InstancePort=80" \
    --subnets subnet-12345

3. نیاز به منابع سخت‌افزاری بالا

یکی از بزرگ‌ترین معایب HA نیاز به منابع سخت‌افزاری اضافی است. برای دستیابی به دسترسی‌پذیری بالا، معمولاً باید گره‌های اضافی، ذخیره‌سازی و شبکه‌های پشتیبان را در سیستم پیاده‌سازی کرد. این منابع اضافی می‌توانند تأثیر زیادی بر روی هزینه‌های اولیه و عملیاتی داشته باشند.

چالش‌ها:

• نیاز به حافظه، پردازنده و ذخیره‌سازی اضافی برای هر گره.
• نیاز به پهنای باند بالا برای ارتباط بین گره‌ها و انتقال داده‌ها.
• افزایش مصرف انرژی به دلیل وجود گره‌های اضافی.

راه‌حل‌ها:

می‌توان با انتخاب دقیق سخت‌افزار و بهینه‌سازی منابع موجود، نیاز به منابع اضافی را به حداقل رساند. به علاوه، استفاده از مجازی‌سازی و سرویس‌های ابری می‌تواند به کاهش هزینه‌ها و منابع کمک کند.

مثال استفاده از مجازی‌سازی در HA: در محیط‌های مجازی‌شده، مانند VMware یا KVM، می‌توان از چندین ماشین مجازی برای پشتیبانی از HA استفاده کرد که هزینه‌های سخت‌افزاری را کاهش می‌دهد و در عین حال از قابلیت‌های دسترسی‌پذیری بالا بهره می‌برد.

vim-cmd vmsvc/createdummyvm "my-ha-vm" /vmfs/volumes/datastore1

این دستور یک ماشین مجازی جدید ایجاد می‌کند که می‌تواند به‌عنوان بخشی از یک کلاستر HA استفاده شود.

جمع‌بندی

پیاده‌سازی HA مزایای زیادی به همراه دارد، اما معایبی نیز دارد که شامل پیچیدگی پیکربندی، هزینه‌های اضافی و نیاز به منابع سخت‌افزاری بالا می‌شود:

• پیچیدگی پیکربندی: نیاز به پیکربندی دقیق و هماهنگی بین گره‌ها دارد.
• هزینه‌های اضافی: نیاز به منابع اضافی برای گره‌های پشتیبان، سخت‌افزار، نرم‌افزار و نیروی انسانی.
• نیاز به منابع سخت‌افزاری بالا: برای پیاده‌سازی HA، به منابع اضافی پردازشی، ذخیره‌سازی و شبکه‌ای نیاز است.

با برنامه‌ریزی دقیق، استفاده از منابع موجود و بهینه‌سازی هزینه‌ها، می‌توان این معایب را به حداقل رساند و از مزایای HA به‌طور مؤثر بهره‌برداری کرد.

 [/cdb_course_lesson][cdb_course_lesson title=”فصل 10. چرا لینوکس برای پیاده‌سازی HA مناسب است؟”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”ویژگی‌های لینوکس که آن را به یک انتخاب مناسب برای HA تبدیل می‌کند” subtitle=”توضیحات کامل”]سیستم‌عامل لینوکس به دلیل ویژگی‌های خاص و انعطاف‌پذیری که دارد، به یکی از بهترین انتخاب‌ها برای پیاده‌سازی سیستم‌های High Availability (HA) تبدیل شده است. این ویژگی‌ها باعث می‌شوند که لینوکس در کنار توانمندی‌های خود در بهینه‌سازی منابع، در دسترس‌پذیری بالا و تحمل خرابی، یک پلتفرم مناسب برای کسب‌وکارهایی باشد که به پایداری و دسترسی ۲۴/۷ نیاز دارند.

1. مقیاس‌پذیری و انعطاف‌پذیری

لینوکس به‌طور ذاتی مقیاس‌پذیر است، به این معنی که می‌توان به راحتی منابع سخت‌افزاری را اضافه یا کم کرد تا نیازهای بار کاری متغیر را مدیریت کند. این ویژگی به‌ویژه برای HA حیاتی است، زیرا سیستم‌های HA معمولاً به گره‌های متعدد و منابع اضافی نیاز دارند تا در صورت بروز خرابی، خدمات به‌طور مداوم ادامه یابد.

چالش‌ها:

• هنگام طراحی یک کلاستر HA در لینوکس، نیاز به توجه به منابع سخت‌افزاری و تخصیص بهینه آن‌ها است.

راه‌حل‌ها:

• از Virtualization (مجازی‌سازی) یا Cloud Solutions برای مدیریت منابع به‌صورت مقیاس‌پذیر استفاده کنید.

2. ابزارهای پشتیبانی از HA در لینوکس

لینوکس مجموعه‌ای از ابزارهای قوی برای مدیریت High Availability دارد که می‌تواند در طراحی و پیاده‌سازی کلاسترهای HA بسیار مفید باشد. برخی از این ابزارها عبارتند از:

• Pacemaker: این ابزار برای مدیریت منابع کلاستر و مدیریت فرآیندهای Failover و Failback استفاده می‌شود. Pacemaker به‌طور خودکار سرویس‌ها را به گره‌های دیگر منتقل می‌کند تا از قطع شدن آن‌ها جلوگیری شود.مثال نصب Pacemaker:

  sudo apt-get install pacemaker
  

• Corosync: این ابزار به‌عنوان سیستم ارتباطی برای کلاسترهای لینوکس عمل می‌کند و نقش مهمی در هماهنگی و همگام‌سازی گره‌ها در سیستم‌های HA ایفا می‌کند.مثال نصب Corosync:

  sudo apt-get install corosync
  

• DRBD (Distributed Replicated Block Device): این ابزار برای همگام‌سازی داده‌ها بین گره‌ها استفاده می‌شود. DRBD امکان ذخیره‌سازی داده‌ها بر روی دیسک‌های مختلف و همگام‌سازی آن‌ها را فراهم می‌کند.مثال نصب DRBD:

  sudo apt-get install drbd-utils
  

3. پشتیبانی از Replication و Redundancy

لینوکس به‌طور گسترده از Replication و Redundancy پشتیبانی می‌کند که از اصلی‌ترین تکنیک‌ها برای حفظ High Availability در سیستم‌های پیچیده است. به‌ویژه برای سیستم‌های دیتابیس، لینوکس راه‌حل‌هایی برای Replication داده‌ها و پشتیبان‌گیری فراهم می‌آورد. از جمله این ابزارها می‌توان به MySQL و PostgreSQL اشاره کرد که قابلیت Replication داده‌ها را در محیط‌های HA فراهم می‌کنند.

چالش‌ها:

• همگام‌سازی داده‌ها بین گره‌ها به‌ویژه در محیط‌های توزیع‌شده می‌تواند پیچیده باشد.

راه‌حل‌ها:

• استفاده از ابزارهای Database Replication مانند MySQL Replication یا PostgreSQL Streaming Replication.

4. بهینه‌سازی مصرف منابع و مدیریت توان

لینوکس به‌عنوان یک سیستم‌عامل سبک و کارآمد، از منابع سیستمی به‌طور بهینه استفاده می‌کند. این امر در محیط‌های HA بسیار اهمیت دارد، زیرا منابع سخت‌افزاری باید به‌صورت بهینه مدیریت شوند تا از مشکلات عملکردی یا قطعی‌ها جلوگیری شود. لینوکس توانایی بالایی در مدیریت پردازنده‌ها، حافظه و ذخیره‌سازی در هنگام نیاز دارد و این امر باعث می‌شود که استفاده از آن در سیستم‌های High Availability بسیار مفید باشد.

چالش‌ها:

• مصرف منابع باید به‌طور دقیق مدیریت شود تا در صورت بروز خرابی، سیستم بتواند از منابع به‌درستی استفاده کند.

راه‌حل‌ها:

• استفاده از ابزارهای Load Balancing و Resource Management مانند HAProxy و Nginx برای توزیع بار و مدیریت منابع.

5. پشتیبانی از Virtualization و Cloud Computing

لینوکس از فناوری‌های مجازی‌سازی و ابری به‌طور کامل پشتیبانی می‌کند. این ویژگی‌ها امکان مقیاس‌پذیری و انعطاف‌پذیری بیشتر را فراهم می‌آورند. با استفاده از KVM (Kernel-based Virtual Machine) یا Xen می‌توان گره‌های مجازی ایجاد کرده و آن‌ها را در صورت لزوم به‌راحتی مقیاس‌بندی یا مهاجرت داد. این ویژگی در ساخت سیستم‌های HA با استفاده از Cloud Platforms مانند AWS، Azure یا Google Cloud بسیار موثر است.

چالش‌ها:

• هماهنگ‌سازی دقیق منابع مجازی و فیزیکی در کلاسترهای لینوکس می‌تواند پیچیده باشد.

راه‌حل‌ها:

• استفاده از ابزارهای مدیریت منابع در فضای ابری مانند AWS Auto Scaling یا Google Cloud Managed Instance Groups.

6. پشتیبانی از Load Balancing

لینوکس به‌طور طبیعی از توزیع بار (Load Balancing) پشتیبانی می‌کند. ابزارهایی مانند HAProxy و Nginx به‌طور گسترده برای مدیریت ترافیک ورودی و توزیع آن به گره‌های مختلف کلاستر استفاده می‌شوند. این ویژگی برای حفظ High Availability بسیار حیاتی است زیرا از Single Point of Failure جلوگیری می‌کند.

چالش‌ها:

• نیاز به تنظیمات دقیق برای توزیع بار به‌صورت بهینه بین گره‌ها.

راه‌حل‌ها:

• استفاده از ابزارهای HAProxy و Nginx برای توزیع بار به گره‌ها به‌صورت متوازن.

مثال نصب HAProxy:

sudo apt-get install haproxy

جمع‌بندی

سیستم‌عامل لینوکس با ویژگی‌های خاصی که دارد، آن را به یک انتخاب ایده‌آل برای پیاده‌سازی سیستم‌های High Availability تبدیل می‌کند. ویژگی‌های مهم لینوکس شامل:

• مقیاس‌پذیری و انعطاف‌پذیری برای مدیریت منابع.
• ابزارهای پشتیبانی از HA مانند Pacemaker، Corosync و DRBD.
• پشتیبانی از Replication و Redundancy برای جلوگیری از از دست رفتن داده‌ها.
• بهینه‌سازی مصرف منابع و مدیریت توان به‌طور مؤثر.
• پشتیبانی از مجازی‌سازی و فناوری‌های ابری.
• توزیع بار (Load Balancing) به‌وسیله ابزارهایی مانند HAProxy و Nginx.

این ویژگی‌ها موجب می‌شوند که لینوکس به یک پلتفرم قدرتمند و انعطاف‌پذیر برای پیاده‌سازی سیستم‌های High Availability تبدیل شود و به کسب‌وکارها این امکان را بدهد تا سرویس‌های خود را با اطمینان و بدون قطعی ارائه دهند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”پشتیبانی از ابزارهای مختلف کلاسترینگ مانند Pacemaker و Corosync” subtitle=”توضیحات کامل”]یکی از ویژگی‌های برجسته لینوکس برای پیاده‌سازی سیستم‌های High Availability (HA)، پشتیبانی قوی از ابزارهای مختلف کلاسترینگ است. ابزارهایی مانند Pacemaker و Corosync به‌طور خاص برای مدیریت و هماهنگی گره‌ها در کلاسترهای HA طراحی شده‌اند و نقش حیاتی در فراهم کردن دسترسی مداوم و حفظ پایداری سیستم‌ها دارند.

1. Pacemaker: مدیریت منابع و هماهنگی کلاستر

Pacemaker یکی از مهم‌ترین ابزارهای Cluster Resource Manager (CRM) است که وظیفه اصلی آن مدیریت و نظارت بر منابع مختلف در کلاسترهای HA است. این ابزار به‌ویژه برای پیاده‌سازی مکانیزم‌های Failover و Failback در صورت بروز خرابی‌ها استفاده می‌شود.

• وظایف اصلی Pacemaker:
  • مدیریت منابع: Pacemaker منابع مختلفی مانند سرویس‌ها، دستگاه‌ها یا فرآیندها را در کلاستر مدیریت می‌کند و از آن‌ها نظارت به عمل می‌آورد.
  • Failover: در صورت بروز خرابی در یک گره، Pacemaker به‌طور خودکار سرویس‌ها را به گره‌های سالم دیگر منتقل می‌کند.
  • تخصیص منابع: Pacemaker منابع موجود را به‌طور مؤثر بین گره‌ها تقسیم می‌کند و از استفاده بهینه از منابع در کلاستر اطمینان می‌یابد.
• پیکربندی Pacemaker: ابتدا، نیاز به نصب Pacemaker دارید. برای نصب، می‌توانید از دستور زیر استفاده کنید:نصب Pacemaker در لینوکس:

  sudo apt-get update
  sudo apt-get install pacemaker
  

  پس از نصب، برای راه‌اندازی کلاستر HA از دستورات مربوطه برای پیکربندی استفاده می‌شود.

  مثال پیکربندی ساده Pacemaker:

  sudo pcs cluster auth node1 node2 -u hacluster -p password
  sudo pcs cluster setup --start --name mycluster node1 node2
  sudo pcs resource create myresource ocf:heartbeat:Dummy op monitor interval=30s
  

  در این مثال، از pcs برای راه‌اندازی کلاستر و ایجاد یک منبع ساده استفاده شده است.

2. Corosync: ارتباطات کلاستر و همگام‌سازی گره‌ها

Corosync یک ابزار ضروری در کلاسترهای لینوکس است که وظیفه مدیریت ارتباطات بین گره‌ها و هماهنگ‌سازی وضعیت گره‌ها را دارد. Corosync به‌عنوان یک سیستم ارتباطی در کلاستر عمل می‌کند و اطلاعات مربوط به وضعیت گره‌ها، منابع، و فرآیندها را همگام‌سازی می‌کند.

• ویژگی‌های اصلی Corosync:
  • مدیریت ارتباطات: Corosync به‌طور مؤثر داده‌ها و وضعیت گره‌ها را بین اعضای کلاستر تبادل می‌کند.
  • اتصال گره‌ها: این ابزار تضمین می‌کند که تمامی گره‌های کلاستر به یکدیگر متصل و قادر به ارسال پیام‌های وضعیت و هماهنگی باشند.
  • اعتمادسازی و تایید وضعیت گره‌ها: Corosync در سطح گره‌ها، اطلاعات دقیق در مورد وضعیت آن‌ها و همگام‌سازی داده‌ها را ارائه می‌دهد.
• نصب Corosync: برای نصب Corosync از دستور زیر استفاده می‌شود:نصب Corosync در لینوکس:

  sudo apt-get update
  sudo apt-get install corosync
  

  پس از نصب، می‌توان از Corosync برای ایجاد ارتباط بین گره‌ها و همگام‌سازی وضعیت استفاده کرد.

  مثال پیکربندی Corosync:

  sudo corosync-cfgtool -s
  

  این دستور وضعیت کلاستر را نشان می‌دهد و گره‌ها را شناسایی می‌کند.

3. ارتباط میان Pacemaker و Corosync

در سیستم‌های HA لینوکس، Pacemaker و Corosync معمولاً به‌طور مشترک برای ایجاد کلاسترهای پایداری استفاده می‌شوند. Corosync ارتباطات میان گره‌ها را فراهم می‌آورد و اطلاعات وضعیت آن‌ها را همگام‌سازی می‌کند، در حالی که Pacemaker برای مدیریت منابع و تصمیم‌گیری در مورد جابجایی منابع یا Failover استفاده می‌شود.

• نحوه تعامل Pacemaker و Corosync:
  • Corosync به‌عنوان لایه ارتباطی میان گره‌ها عمل کرده و وضعیت گره‌ها را با یکدیگر هماهنگ می‌کند.
  • Pacemaker بر اساس اطلاعات وضعیت که از Corosync به‌دست می‌آید، تصمیم می‌گیرد که منابع را به کدام گره اختصاص دهد یا در صورت بروز خرابی به کدام گره منتقل کند.

4. مزایای استفاده از Pacemaker و Corosync در کلاسترهای HA

• اتصال قوی و پایدار میان گره‌ها: استفاده از Corosync به‌عنوان لایه ارتباطی سبب می‌شود که گره‌ها بتوانند به‌طور مداوم با یکدیگر در ارتباط باشند و وضعیت یکدیگر را به‌روزرسانی کنند.
• مدیریت خودکار منابع: Pacemaker با مدیریت منابع به‌طور خودکار و انجام فرآیندهای Failover و Failback، سیستم را در مواجهه با خرابی‌ها پایدار نگه می‌دارد.
• پشتیبانی از انواع منابع: Pacemaker می‌تواند منابع مختلف از جمله سرویس‌ها، دستگاه‌ها و فرآیندها را مدیریت کند و از High Availability آن‌ها اطمینان حاصل کند.
• مقیاس‌پذیری بالا: این ابزارها به‌طور مؤثر مقیاس‌پذیر هستند و به‌راحتی می‌توانند گره‌های جدیدی را به کلاستر اضافه کنند.

جمع‌بندی

• Pacemaker و Corosync دو ابزار اصلی برای پیاده‌سازی کلاسترهای High Availability در لینوکس هستند که هر کدام نقش خاص خود را دارند. Pacemaker مسئول مدیریت منابع و جابجایی آن‌ها در صورت خرابی است، در حالی که Corosync مسئولیت ارتباطات بین گره‌ها و همگام‌سازی وضعیت گره‌ها را بر عهده دارد.
• ترکیب این دو ابزار به شما امکان می‌دهد که یک کلاستر HA با پایداری بالا، مدیریت خودکار منابع و مقیاس‌پذیری ایجاد کنید.
• استفاده از این ابزارها در کلاسترهای لینوکسی نه تنها باعث افزایش دسترسی و پایداری سیستم‌ها می‌شود، بلکه به کسب‌وکارها این اطمینان را می‌دهد که سرویس‌های آن‌ها حتی در صورت بروز خرابی‌های غیرمنتظره، همچنان در دسترس خواهند بود.

[/cdb_course_lesson][/cdb_course_lessons]

[cdb_course_lessons title=”بخش 2. معرفی کلاسترهای در دسترس‌پذیری بالا در لینوکس”][cdb_course_lesson title=”فصل 1. مفهوم کلاسترهای در دسترس‌پذیری بالا (HA)”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تعریف کلاسترهای HA و ارتباط آن با اطمینان از دسترس‌پذیری سیستم” subtitle=”توضیحات کامل”]کلاسترهای در دسترس‌پذیری بالا (HA Clusters) مجموعه‌ای از سرورها یا گره‌ها هستند که با همکاری یکدیگر برای اطمینان از عملکرد مستمر و بدون وقفه یک سرویس یا برنامه طراحی شده‌اند. هدف اصلی این کلاسترها، کاهش زمان خرابی و افزایش دسترس‌پذیری سیستم‌ها و سرویس‌ها به وسیله توزیع بار و مدیریت صحیح منابع است.

در یک سیستم HA، در صورتی که یکی از گره‌ها یا سرورها با مشکل مواجه شود یا خراب شود، بار به گره دیگری منتقل می‌شود و خدمات به طور پیوسته در دسترس خواهند بود. این امر با استفاده از تکنیک‌هایی مانند Replication (تکرار داده‌ها)، Failover (جابجایی در صورت خرابی)، و Load Balancing (توزیع بار) تحقق می‌یابد.

ارتباط کلاسترهای HA با دسترس‌پذیری سیستم

در دنیای فناوری اطلاعات و شبکه‌ها، دسترس‌پذیری به معنای توانایی دسترسی به سرویس‌ها و سیستم‌ها به صورت پیوسته و بدون وقفه است. یکی از بزرگ‌ترین چالش‌های سیستم‌های IT و شبکه، زمان خرابی یا Downtime است که می‌تواند باعث اختلال در خدمات و مشکلات جدی برای کاربران شود.

کلاسترهای HA با ایجاد چندین نقطه ذخیره‌سازی و پردازش داده در چند گره مختلف، به این اطمینان می‌رسند که در صورت خرابی یکی از گره‌ها، گره‌های دیگر بتوانند جایگزین آن شوند و بدون هیچ وقفه‌ای به سرویس‌دهی ادامه دهند.

مثال عملی از نحوه پیاده‌سازی کلاستر HA

برای درک بهتر این مفهوم، فرض کنید که در حال پیاده‌سازی یک وب‌سرور به منظور ارائه یک سرویس آنلاین هستید. در این حالت، شما می‌خواهید اطمینان حاصل کنید که در صورت بروز خرابی یا قطع ارتباط یکی از سرورها، سرور دیگری جایگزین آن شود و سرویس همچنان در دسترس باشد.

یکی از روش‌های معمول برای پیاده‌سازی چنین کلاستری استفاده از ابزارهایی مانند Pacemaker و Corosync است که برای هماهنگی و مدیریت منابع در کلاسترهای لینوکسی استفاده می‌شوند.

مراحل پیکربندی یک کلاستر HA در لینوکس

برای راه‌اندازی یک کلاستر HA در لینوکس با استفاده از Pacemaker و Corosync، مراحل زیر را می‌توان دنبال کرد:

1. نصب بسته‌های لازم برای نصب ابزارهای مورد نیاز، از دستورات زیر استفاده کنید:

   sudo apt-get update
   sudo apt-get install pacemaker corosync
   

2. پیکربندی Corosync پس از نصب Corosync، شما باید فایل پیکربندی آن را ویرایش کنید که معمولاً در مسیر /etc/corosync/corosync.conf قرار دارد. برای مثال:

   sudo nano /etc/corosync/corosync.conf
   

   در این فایل، باید تنظیمات شبکه و گره‌ها را مشخص کنید:

   totem {
       version: 2
       cluster_name: mycluster
       transport: udpu
   }
   
   quorum {
       provider: corosync_votequorum
   }
   
   logging {
       fileline: on
       to_stderr: yes
       to_logfile: yes
       logfile: /var/log/corosync/corosync.log
       log_max: 1024
   }
   

3. پیکربندی Pacemaker پس از تنظیم Corosync، باید Pacemaker را برای مدیریت منابع و هماهنگی میان گره‌ها پیکربندی کنید. این کار را می‌توان با استفاده از دستور زیر انجام داد:

   sudo pcs cluster auth node1 node2 -u hacluster -p password
   

   سپس، کلاستر را راه‌اندازی می‌کنیم:

   sudo pcs cluster setup --name mycluster node1 node2
   sudo pcs cluster start --all
   

4. ایجاد و پیکربندی منابع حالا که کلاستر راه‌اندازی شده است، می‌توانیم منابع مورد نظر خود را تعریف کنیم. به عنوان مثال، فرض کنید که می‌خواهید یک سرویس وب را در کلاستر راه‌اندازی کنید. برای این کار از دستور زیر استفاده کنید:

   sudo pcs resource create WebServer ocf:heartbeat:apache \
       op monitor interval=30s
   

   این دستور یک سرویس Apache را به عنوان یک منبع در کلاستر ایجاد می‌کند که در صورت خرابی یک گره، به گره دیگر منتقل خواهد شد.

جمع‌بندی

کلاسترهای HA با فراهم آوردن یک محیط توزیع‌شده و مقاوم در برابر خرابی، از دسترس‌پذیری بالا و پیوسته سیستم‌ها و سرویس‌ها اطمینان حاصل می‌کنند. این کلاسترها با استفاده از ابزارهایی مانند Pacemaker و Corosync به طور مؤثر منابع را مدیریت و هماهنگ می‌کنند تا در صورت بروز مشکلات یا خرابی، سیستم‌ها بدون وقفه به فعالیت خود ادامه دهند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”اهمیت استفاده از کلاسترها برای افزایش تحمل خطا و مقیاس‌پذیری” subtitle=”توضیحات کامل”]کلاسترها ابزارهای مهمی در زمینه فناوری اطلاعات و شبکه‌ها هستند که برای افزایش تحمل خطا و مقیاس‌پذیری سیستم‌ها طراحی شده‌اند. با استفاده از کلاسترها، می‌توان اطمینان حاصل کرد که سیستم‌ها هم در برابر خرابی‌ها مقاوم بوده و هم بتوانند بار بیشتری را بدون افت کارایی تحمل کنند. این ویژگی‌ها باعث می‌شوند که کلاسترها برای سیستم‌های مهم و حیاتی که نیاز به دسترس‌پذیری بالا و عملکرد بهینه دارند، بسیار مناسب باشند.

1. تحمل خطا (Fault Tolerance)

یکی از ویژگی‌های کلیدی کلاسترها، تحمل خطا است. در سیستم‌هایی که تنها یک گره (یا سرور) برای ارائه خدمات وجود دارد، هرگونه خرابی می‌تواند به توقف کامل سرویس منجر شود. اما در سیستم‌هایی که از کلاستر استفاده می‌کنند، اطلاعات و پردازش‌ها بین چندین گره تقسیم می‌شود. این ویژگی باعث می‌شود که حتی در صورت خرابی یک گره، سایر گره‌ها همچنان قادر به ادامه ارائه خدمات باشند.

کلاسترها با استفاده از مکانیزم‌هایی مانند Failover (انتقال خودکار بار به گره‌های دیگر در صورت خرابی) و Replication (تکرار داده‌ها در چندین گره)، تضمین می‌کنند که در صورت خرابی یک گره، سیستم همچنان فعال بماند و به کار خود ادامه دهد.

2. مقیاس‌پذیری (Scalability)

کلاسترها نه تنها در برابر خطاها مقاوم هستند، بلکه می‌توانند به راحتی برای مدیریت بارهای اضافی گسترش یابند. مقیاس‌پذیری به این معنی است که می‌توان به راحتی منابع جدیدی به کلاستر اضافه کرد تا بتوانند درخواست‌های بیشتری را پردازش کنند بدون اینکه عملکرد سیستم تحت تأثیر قرار گیرد.

کلاسترها برای مقیاس‌پذیری از دو روش استفاده می‌کنند:

• مقیاس‌پذیری عمودی (Vertical Scaling): اضافه کردن منابع به گره‌ها به طور مثال با ارتقاء پردازنده یا حافظه. این روش محدودیت‌هایی از نظر ظرفیت دارد.
• مقیاس‌پذیری افقی (Horizontal Scaling): اضافه کردن گره‌های جدید به کلاستر برای توزیع بهتر بار و افزایش ظرفیت پردازش. این روش به راحتی می‌تواند ظرفیت را به صورت نامحدود افزایش دهد.

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

فرض کنید که شما در حال پیاده‌سازی یک پایگاه داده توزیع‌شده مانند MySQL Cluster هستید که نیاز به تحمل خطا و مقیاس‌پذیری بالا دارد. در این حالت، شما می‌توانید چندین گره پایگاه داده را در سراسر شبکه راه‌اندازی کنید و داده‌ها را بین آن‌ها تکرار کنید. در صورتی که یکی از گره‌ها خراب شود، سایر گره‌ها می‌توانند به طور خودکار داده‌ها را ارائه دهند و عملیات پایگاه داده ادامه یابد.

مراحل راه‌اندازی یک کلاستر MySQL برای تحمل خطا و مقیاس‌پذیری

1. نصب MySQL Clusterبرای نصب MySQL Cluster بر روی سیستم‌های مختلف، ابتدا باید بسته‌های لازم را نصب کنید:

   sudo apt-get update
   sudo apt-get install mysql-server mysql-client ndb-cluster
   

2. پیکربندی گره‌های MySQL Clusterبرای تنظیم و پیکربندی گره‌های مختلف MySQL Cluster، ابتدا باید فایل پیکربندی my.cnf را در هر سرور و گره ویرایش کنید. فایل پیکربندی معمولاً در مسیر /etc/mysql/my.cnf قرار دارد و به شکل زیر تنظیم می‌شود:

   [mysqld]
   ndbcluster
   binlog-format=row
   datadir=/var/lib/mysql
   
   [ndb_mgmd]
   NodeId=1
   Hostname=192.168.1.1
   DataDir=/var/lib/mysql-cluster
   
   [ndbd default]
   NoOfReplicas=2
   DataMemory=256M
   IndexMemory=128M
   

3. راه‌اندازی و مدیریت گره‌هاپس از پیکربندی، باید گره‌ها را راه‌اندازی کنید:
   • راه‌اندازی گره مدیریت (Management Node):

     sudo ndb_mgmd -f /etc/mysql/my.cnf --initial
     

   • راه‌اندازی گره‌های داده (Data Nodes):

     sudo ndbd --ndb-nodeid=2
     

   • راه‌اندازی گره‌های SQL (SQL Nodes):

     sudo mysqld --ndbcluster
     

جمع‌بندی

کلاسترها ابزارهای بسیار مفیدی برای افزایش تحمل خطا و مقیاس‌پذیری سیستم‌ها هستند. با استفاده از کلاسترهای HA، می‌توان از در دسترس‌پذیری بالا و عملکرد بی‌وقفه اطمینان حاصل کرد. همچنین، با استفاده از مقیاس‌پذیری افقی، می‌توان منابع جدید را به راحتی به سیستم اضافه کرده و بار بیشتری را بدون کاهش کارایی پردازش کرد. این ویژگی‌ها به ویژه برای سیستم‌های حیاتی و پرمصرف مانند پایگاه‌های داده، وب‌سرورها و سرویس‌های ابری حیاتی هستند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 2. اجزای اصلی یک کلاستر HA در لینوکس”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”بررسی گره‌ها (Nodes) و نوع ارتباطات بین آن‌ها” subtitle=”توضیحات کامل”]در سیستم‌های کلاستری، گره‌ها (Nodes) اجزای اصلی هستند که وظایف مختلف را به عهده دارند و با همکاری یکدیگر، بار کاری را به اشتراک می‌گذارند و از تحمل خطا و مقیاس‌پذیری اطمینان حاصل می‌کنند. هر گره در کلاستر می‌تواند نقش متفاوتی ایفا کند، و نوع ارتباطات بین گره‌ها بسیار مهم است تا عملکرد سیستم بهینه و بی‌وقفه باقی بماند.

1. انواع گره‌ها در کلاستر

در یک کلاستر معمولی، گره‌ها می‌توانند نقش‌های مختلفی داشته باشند. این نقش‌ها بستگی به نوع سیستم کلاستری دارند، اما به طور کلی می‌توان گره‌ها را به چند نوع مختلف تقسیم‌بندی کرد:

• گره‌های مدیریت (Management Nodes): گره‌های مدیریت، مسئول نظارت بر وضعیت کلی کلاستر و هماهنگی بین گره‌ها هستند. این گره‌ها اطلاعات مربوط به پیکربندی کلاستر و وضعیت گره‌ها را نگه‌داری می‌کنند و در صورت بروز مشکلات، اطلاعات لازم برای بازیابی و بازیابی داده‌ها را فراهم می‌آورند. به طور معمول، تنها یک گره مدیریت در یک کلاستر وجود دارد، اما در صورت نیاز می‌توان گره‌های مدیریت اضافی نیز اضافه کرد.
• گره‌های داده (Data Nodes): گره‌های داده مسئول ذخیره‌سازی و مدیریت داده‌ها هستند. در بسیاری از سیستم‌های کلاستری، داده‌ها بین چندین گره توزیع می‌شود و هر گره داده‌ها را ذخیره می‌کند و درخواست‌های داده را از دیگر گره‌ها پاسخ می‌دهد. این گره‌ها همچنین مسئول پردازش داده‌ها و انجام محاسبات مختلف هستند.
• گره‌های SQL (SQL Nodes): این گره‌ها در سیستم‌های کلاستری که از پایگاه‌های داده توزیع‌شده استفاده می‌کنند (مثل MySQL Cluster)، مسئول پردازش درخواست‌های SQL از کاربران و تعامل با گره‌های داده هستند. گره‌های SQL به گره‌های داده متصل می‌شوند و داده‌ها را از آن‌ها می‌خوانند یا می‌نویسند.

2. ارتباطات بین گره‌ها

ارتباطات بین گره‌ها در کلاستر برای هماهنگی و تبادل داده‌ها ضروری است. بسته به نوع کلاستر، چندین نوع ارتباط ممکن است وجود داشته باشد:

• ارتباطات داخلی (Internal Communication): در این نوع ارتباط، گره‌ها مستقیماً با یکدیگر برای تبادل داده‌ها و هماهنگی عملکردها ارتباط برقرار می‌کنند. این ارتباط ممکن است بین گره‌های داده، گره‌های SQL و گره‌های مدیریت برقرار شود. ارتباطات داخلی باید بسیار سریع و بدون تأخیر باشند تا سیستم بتواند عملکرد بهینه‌ای ارائه دهد.
• ارتباطات شبکه‌ای (Network Communication): در کلاسترها، گره‌ها از طریق شبکه به یکدیگر متصل می‌شوند. نوع شبکه‌ای که بین گره‌ها استفاده می‌شود، می‌تواند بر عملکرد کلاستر تأثیر بگذارد. برای سیستم‌های کلاستری با نیاز به عملکرد بالا، معمولاً از شبکه‌های با تأخیر کم و پهنای باند بالا استفاده می‌شود تا تأخیر در انتقال داده‌ها به حداقل برسد.
• Replication (تکرار داده‌ها): در کلاسترهایی که به تحمل خطا نیاز دارند، داده‌ها بین گره‌ها تکرار می‌شود. این فرآیند اطمینان می‌دهد که اگر یکی از گره‌ها از دست برود، داده‌ها همچنان در گره‌های دیگر قابل دسترس باشند. این نوع ارتباطات معمولاً به‌صورت یک‌طرفه یا دوطرفه بین گره‌ها برقرار می‌شود.
• Load Balancing (تعادل بار): یکی از مهم‌ترین نوع ارتباطات در کلاسترهای مقیاس‌پذیر است. این نوع ارتباط باعث می‌شود که بار کاری بین گره‌ها به‌طور مساوی توزیع شود تا هیچ گره‌ای بار بیش‌ازحد را تحمل نکند. در اینجا، گره‌ها با یکدیگر برای تعیین اینکه کدام گره باید درخواست خاصی را پردازش کند، ارتباط برقرار می‌کنند.

3. نحوه هماهنگی و تبادل داده‌ها بین گره‌ها

برای ایجاد هماهنگی بین گره‌ها و تضمین عملکرد صحیح کلاستر، تبادل داده‌ها باید به‌طور دقیق و صحیح انجام شود. این تبادل داده‌ها می‌تواند شامل موارد زیر باشد:

• Syncing (همگام‌سازی داده‌ها): گره‌ها باید به طور مرتب داده‌ها را همگام‌سازی کنند تا از وجود اطلاعات یکسان در تمامی گره‌ها اطمینان حاصل شود. این فرآیند می‌تواند از طریق تکنیک‌هایی مانند Replication انجام شود.
• Failover (انتقال خودکار بار): در صورت بروز خرابی در یکی از گره‌ها، سیستم باید به‌طور خودکار بار را به گره‌های دیگر منتقل کند. این فرآیند نیاز به ارتباط مداوم بین گره‌ها برای شناسایی وضعیت سلامت گره‌ها دارد.
• Heartbeat (ضربان قلب): در بسیاری از کلاسترها، گره‌ها برای بررسی وضعیت سلامت یکدیگر از پیام‌های “ضربان قلب” استفاده می‌کنند. این پیام‌ها به گره‌ها اطلاع می‌دهند که گره‌های دیگر فعال هستند و هیچ‌گونه خرابی در کلاستر وجود ندارد.

4. مثال عملی از تنظیم ارتباطات بین گره‌ها در کلاستر

برای پیاده‌سازی ارتباطات بین گره‌ها در یک کلاستر MySQL Cluster، باید پیکربندی‌های خاصی انجام شود. در اینجا نحوه پیکربندی گره‌ها و ارتباطات آن‌ها به‌طور خلاصه آورده شده است:

1. پیکربندی گره‌های داده:در فایل پیکربندی /etc/mysql/my.cnf برای هر گره داده، باید اطلاعات گره‌های دیگر مشخص شود:

   [ndbd default]
   NoOfReplicas=2
   DataMemory=256M
   IndexMemory=128M
   
   [ndbd]
   NodeId=2
   Hostname=192.168.1.2
   

2. پیکربندی گره‌های مدیریت:فایل پیکربندی گره مدیریت نیز باید به‌گونه‌ای تنظیم شود که به تمامی گره‌ها اطلاع دهد:

   [ndb_mgmd]
   NodeId=1
   Hostname=192.168.1.1
   DataDir=/var/lib/mysql-cluster
   

3. پیکربندی گره‌های SQL:گره‌های SQL باید به گره‌های داده متصل شوند. در فایل پیکربندی MySQL، باید گزینه ndbcluster فعال شود:

   [mysqld]
   ndbcluster
   

جمع‌بندی

گره‌ها در کلاستر نقش‌های مختلفی دارند که شامل گره‌های مدیریت، گره‌های داده و گره‌های SQL است. ارتباطات بین این گره‌ها برای عملکرد صحیح کلاستر ضروری است و می‌تواند شامل ارتباطات داخلی، شبکه‌ای، تکرار داده‌ها، و تعادل بار باشد. همگام‌سازی داده‌ها، انتقال خودکار بار و استفاده از ضربان قلب از جمله تکنیک‌های حیاتی برای هماهنگی گره‌ها و تضمین عملکرد بهینه کلاستر هستند. با پیکربندی درست و ارتباط مؤثر بین گره‌ها، کلاستر می‌تواند به بهبود تحمل خطا و مقیاس‌پذیری کمک کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مفاهیم Resource Management (مدیریت منابع) و Failover (انتقال منابع در صورت خرابی)” subtitle=”توضیحات کامل”]مدیریت منابع و فرآیند انتقال خودکار در صورت خرابی (Failover) دو مفهوم حیاتی در سیستم‌های توزیع‌شده و کلاستری هستند که به بهبود کارایی، قابلیت اطمینان و تحمل خطا کمک می‌کنند. این مفاهیم به‌ویژه در کلاسترهایی که نیاز به مقیاس‌پذیری و در دسترس‌بودن مستمر دارند، اهمیت ویژه‌ای دارند. در این بخش، به تشریح این مفاهیم و نحوه پیاده‌سازی آنها در کلاسترهای مختلف خواهیم پرداخت.

1. مدیریت منابع (Resource Management)

مدیریت منابع به مجموعه‌ای از فرآیندها گفته می‌شود که هدف آن تخصیص، نظارت، و مدیریت بهینه منابع مختلف (مانند CPU، حافظه، فضای ذخیره‌سازی، شبکه و سایر منابع سیستم) در یک محیط توزیع‌شده یا کلاستری است. این فرآیند به‌ویژه در محیط‌های پر ترافیک و مقیاس بزرگ، برای حفظ عملکرد سیستم و جلوگیری از ایجاد گلوگاه‌ها یا از دست دادن منابع حیاتی بسیار مهم است.

انواع منابع در کلاستر

• CPU: تخصیص مناسب زمان پردازشی به گره‌ها برای انجام محاسبات.
• حافظه (Memory): مدیریت حافظه مورد نیاز برای بارگذاری داده‌ها و برنامه‌ها.
• شبکه: تخصیص پهنای باند و کنترل ازدحام در انتقال داده‌ها.
• ذخیره‌سازی: تخصیص فضای ذخیره‌سازی و استفاده از آن به صورت توزیع‌شده در کلاستر.

روش‌های مدیریت منابع

• Dynamic Resource Allocation (تخصیص پویا منابع): در این روش، منابع به‌طور پویا و بر اساس نیازهای لحظه‌ای سیستم به گره‌ها تخصیص می‌یابد. این فرآیند معمولاً در کلاسترهای مدرن استفاده می‌شود و از ابزارهایی مانند Kubernetes و Mesos برای مدیریت منابع استفاده می‌شود.
• Resource Scheduling (برنامه‌ریزی منابع): در این روش، منابع پیش‌بینی شده به گره‌ها تخصیص می‌یابد. این نوع تخصیص معمولاً در سیستم‌هایی که نیاز به عملکرد ثابت دارند، مورد استفاده قرار می‌گیرد.
• Quota Management (مدیریت سهمیه): تخصیص منابع به هر گره بر اساس محدودیت‌هایی که تعیین می‌شود. به‌عنوان مثال، تخصیص محدودیت‌های CPU یا حافظه به هر کاربر یا گره به منظور جلوگیری از استفاده بیش‌ازحد از منابع.

ابزارهای مدیریت منابع

• Kubernetes: ابزاری برای مدیریت منابع در کلاسترهای مبتنی بر Docker که به‌طور خودکار منابع مورد نیاز برای هر اپلیکیشن را مدیریت می‌کند.
• Apache Mesos: ابزاری برای تخصیص منابع در کلاسترهای بزرگ که قادر است منابع را به‌طور مؤثر بین گره‌های مختلف توزیع کند.
• YARN (Yet Another Resource Negotiator): یک سیستم مدیریت منابع برای کلاسترهای Hadoop که منابع را به‌طور بهینه در سطح گره‌ها تخصیص می‌دهد.

2. Failover (انتقال منابع در صورت خرابی)

Failover فرآیندی است که در آن، در صورت خرابی یک بخش از سیستم، منابع به‌طور خودکار به بخشی دیگر از سیستم منتقل می‌شوند تا از قطع خدمات جلوگیری شود. این فرآیند موجب می‌شود که سیستم همیشه در دسترس باقی بماند و کاربران بدون هیچ‌گونه اختلالی بتوانند به خدمات دسترسی داشته باشند.

فرآیند Failover

هنگامی که یکی از گره‌ها یا منابع در سیستم دچار خرابی می‌شود، Failover به‌طور خودکار منابع را به گره‌های سالم دیگر منتقل می‌کند. این انتقال منابع می‌تواند شامل انتقال پردازش‌ها، داده‌ها و درخواست‌ها به گره‌های پشتیبان باشد.

انواع Failover

• Failover در سطح گره (Node-level Failover): در این حالت، در صورتی که یک گره دچار خرابی شود، منابع آن به گره‌های دیگری در کلاستر منتقل می‌شود. این نوع Failover در بسیاری از کلاسترهای مبتنی بر پایگاه داده یا سیستم‌های توزیع‌شده کاربرد دارد.
• Failover در سطح سرویس (Service-level Failover): این نوع Failover برای سیستم‌هایی است که چندین سرویس یا اپلیکیشن را اجرا می‌کنند. در این حالت، در صورت خرابی یک سرویس، سرویس مشابه یا پشتیبان شروع به کار می‌کند.
• Failover در سطح منطقه (Region-level Failover): در این روش، اگر خرابی در سطح یک منطقه (مانند یک دیتاسنتر یا یک شبکه خاص) اتفاق بیافتد، منابع به منطقه دیگری منتقل می‌شوند.

پیاده‌سازی Failover

در بسیاری از سیستم‌ها، Failover به‌طور خودکار پیاده‌سازی می‌شود و نیاز به هیچ‌گونه مداخله دستی ندارد. برای پیاده‌سازی این فرآیند، نیاز به برخی پیکربندی‌ها و ابزارها است.

• Heartbeats: گره‌ها به‌طور مرتب پیام‌های ضربان قلب به یکدیگر ارسال می‌کنند تا از وضعیت سلامت یکدیگر آگاه شوند. در صورت عدم دریافت ضربان قلب از یک گره، سیستم تشخیص می‌دهد که گره دچار خرابی شده و فرآیند Failover شروع می‌شود.
• Cluster Manager: مدیر کلاستر مسئول نظارت بر وضعیت گره‌ها و انجام Failover در صورت خرابی است. این مدیر می‌تواند از ابزارهایی مانند Pacemaker یا Corosync برای مدیریت کلاستر و انجام Failover استفاده کند.
• Replication: در سیستم‌هایی که داده‌ها باید در چندین گره تکرار شوند، Replication به Failover کمک می‌کند تا در صورت خرابی یک گره، داده‌ها از گره‌های دیگر در دسترس باشند.

3. مثال عملی از تنظیم Failover در کلاستر

برای پیاده‌سازی Failover در یک کلاستر MySQL با استفاده از ابزار MHA (MySQL High Availability)، مراحل زیر را دنبال می‌کنیم:

1. پیکربندی فایل MHA: برای تنظیم MHA، ابتدا باید فایل پیکربندی آن را ایجاد کنیم. در فایل پیکربندی /etc/mha/mha.cnf، تنظیمات مربوط به گره‌های اصلی و پشتیبان باید مشخص شود:

   [server default]
   manager_password=your_manager_password
   
   [node1]
   hostname=192.168.1.1
   candidate_master=1
   
   [node2]
   hostname=192.168.1.2
   
   [node3]
   hostname=192.168.1.3
   

2. راه‌اندازی MHA: برای اجرای فرآیند Failover، از دستور زیر برای شروع مدیریت کلاستر استفاده می‌کنیم:

   mha_manager --conf=/etc/mha/mha.cnf
   

3. کنترل وضعیت Failover: پس از پیکربندی، می‌توان وضعیت گره‌ها را بررسی کرد و در صورت نیاز Failover را فعال کرد:

   mha_check --conf=/etc/mha/mha.cnf
   

جمع‌بندی

مدیریت منابع و فرآیند Failover از مفاهیم کلیدی در کلاسترها هستند که به سیستم‌ها کمک می‌کنند تا در برابر خطاها مقاوم باشند و خدمات خود را بدون اختلال ادامه دهند. مدیریت منابع به تخصیص بهینه منابع به گره‌ها کمک می‌کند و Failover باعث می‌شود که در صورت خرابی یک گره یا سرویس، منابع به‌طور خودکار به گره‌های پشتیبان منتقل شوند. با استفاده از ابزارهایی مانند Kubernetes، Pacemaker، و MHA می‌توان این فرآیندها را به‌طور خودکار و کارآمد پیاده‌سازی کرد.[/cdb_course_lesson][cdb_course_lesson title=”فصل 3. مدل‌های مختلف کلاسترهای HA در لینوکس”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”Active/Passive: یکی از گره‌ها به عنوان سرور فعال و دیگری به عنوان سرور پشتیبان” subtitle=”توضیحات کامل”]در این قسمت، به بررسی انواع مدل‌های کلاسترهای High Availability (HA) در سیستم‌عامل لینوکس پرداخته می‌شود. یکی از این مدل‌ها، مدل Active/Passive است که به‌طور گسترده در سیستم‌های HA برای اطمینان از در دسترس بودن دائمی سرویس‌ها استفاده می‌شود. در ادامه، نحوه عملکرد این مدل و مزایا و معایب آن به‌تفصیل توضیح داده خواهد شد.

1. مدل Active/Passive

مدل Active/Passive یکی از ساده‌ترین و پرکاربردترین مدل‌ها در ایجاد کلاسترهای HA است. در این مدل، تنها یک گره به‌عنوان سرور فعال (Active) کار می‌کند و باقی گره‌ها به‌عنوان سرور پشتیبان (Passive) در حالت آماده‌باش قرار دارند. گره‌های پشتیبان تنها در صورتی وارد عمل می‌شوند که گره فعال دچار خرابی شود.

ویژگی‌های مدل Active/Passive:

• گره فعال (Active Node): این گره به‌طور دائم در حال پردازش درخواست‌ها و اجرای سرویس‌ها است. به‌عبارتی، این گره تمام بار کاری (Workload) را تحمل می‌کند.
• گره پشتیبان (Passive Node): این گره به‌طور کامل غیر فعال است و تنها منتظر است تا در صورت خرابی گره فعال، وظایف آن را به‌عهده بگیرد. گره پشتیبان معمولاً در حالت نظارت (Monitor) قرار دارد تا از سلامت گره فعال مطلع شود.
• Failover: اگر گره فعال دچار خرابی شود، گره پشتیبان به‌طور خودکار وارد عمل شده و سرویس‌ها را از سر می‌گیرد. این فرآیند به‌نام Failover شناخته می‌شود.

نحوه عملکرد مدل Active/Passive:

1. فعال بودن گره‌ها: ابتدا گره فعال به‌طور کامل وظایف خود را انجام می‌دهد، مانند پردازش درخواست‌های ورودی و نگهداری داده‌ها.
2. نظارت مداوم: گره پشتیبان به‌طور مداوم وضعیت گره فعال را بررسی می‌کند. این نظارت می‌تواند شامل ارسال ضربان قلب (Heartbeat) باشد تا از سلامت گره فعال مطلع شود.
3. تشخیص خرابی: اگر گره فعال دچار خرابی شود (مثلاً به دلایل نرم‌افزاری یا سخت‌افزاری)، گره پشتیبان این خرابی را شناسایی کرده و وارد عمل می‌شود.
4. انتقال خودکار: پس از شناسایی خرابی، گره پشتیبان به‌طور خودکار سرویس‌ها و بار کاری گره فعال را به‌عهده می‌گیرد و به گره فعال تبدیل می‌شود.
5. بازگشت به حالت اولیه (Failback): زمانی که گره فعال دوباره به حالت پایدار رسید، ممکن است بار کاری به آن بازگردانده شود.

مزایای مدل Active/Passive:

• سادگی پیاده‌سازی: پیاده‌سازی مدل Active/Passive نسبت به سایر مدل‌ها ساده‌تر است و نیاز به مدیریت پیچیده‌ای ندارد.
• افزایش در دسترس‌بودن (Uptime): در صورت خرابی گره فعال، انتقال به گره پشتیبان باعث افزایش زمان دسترس‌پذیری سیستم می‌شود.
• هزینه کمتر: به دلیل نیاز به یک گره پشتیبان که تنها در صورت خرابی وارد عمل می‌شود، هزینه‌ها نسبت به مدل‌های دیگر معمولاً کمتر است.

معایب مدل Active/Passive:

• استفاده ناکارآمد از منابع: گره پشتیبان در حالت غیرفعال باقی می‌ماند و منابع آن به‌طور کامل استفاده نمی‌شوند. این امر ممکن است موجب هدررفت منابع شود.
• زمان تأخیر در Failover: فرآیند انتقال خودکار از گره فعال به گره پشتیبان ممکن است زمان‌بر باشد، به‌ویژه در سیستم‌هایی که نیاز به عملکرد فوری دارند.
• بازیابی داده‌ها: ممکن است در برخی شرایط، داده‌های موجود در گره فعال قبل از خرابی به گره پشتیبان منتقل نشود و این امر منجر به از دست رفتن داده‌ها شود.

2. پیکربندی Active/Passive در لینوکس با استفاده از Pacemaker

برای پیاده‌سازی کلاسترهای Active/Passive در لینوکس، می‌توان از ابزار Pacemaker که یکی از محبوب‌ترین ابزارهای مدیریت کلاسترهای HA است، استفاده کرد. Pacemaker به شما امکان می‌دهد که گره‌های Active/Passive را مدیریت کنید و فرآیندهای Failover و Failback را به‌صورت خودکار انجام دهید.

مراحل پیکربندی Pacemaker:

1. نصب Pacemaker: برای نصب Pacemaker بر روی هر دو گره (Active و Passive) از دستورات زیر استفاده می‌کنیم:

   sudo apt-get install pacemaker corosync
   

2. پیکربندی Corosync: Corosync مسئول نظارت و ارتباطات بین گره‌ها است. فایل پیکربندی Corosync معمولاً در مسیر /etc/corosync/corosync.conf قرار دارد. پیکربندی آن به‌صورت زیر خواهد بود:

   totem {
       version: 2
       cluster_name: mycluster
       secauth: off
       interface {
           ringnumber: 0
           bindnetaddr: 192.168.1.0
           mcastaddr: 239.255.1.1
           mcastport: 5405
       }
   }
   
   logging {
       fileline: off
       to_stderr: no
       to_logfile: yes
       logfile: /var/log/corosync.log
       log_debug: off
       log_info: on
   }
   

3. راه‌اندازی Pacemaker: برای راه‌اندازی Pacemaker و شروع نظارت بر گره‌ها، دستور زیر را اجرا می‌کنیم:

   sudo systemctl start pacemaker
   sudo systemctl enable pacemaker
   

4. ایجاد یک Resource برای سرویس‌ها: حالا می‌توانیم منابع (Resources) را برای سرویس‌ها تعریف کنیم. برای مثال، فرض کنید که می‌خواهیم یک سرویس HTTP (مثل Apache) را مدیریت کنیم. ابتدا یک Resource برای Apache ایجاد می‌کنیم:

   sudo pcs resource create apache-service ocf:heartbeat:apache op monitor interval=30s
   

5. تنظیم Failover: پس از پیکربندی منابع، باید Failover را تنظیم کنیم تا در صورت خرابی گره فعال، گره پشتیبان وارد عمل شود. دستور زیر برای این کار استفاده می‌شود:

   sudo pcs resource move apache-service node2
   

6. بررسی وضعیت کلاستر: برای بررسی وضعیت کلاستر و اطمینان از صحت عملکرد آن، دستور زیر را اجرا می‌کنیم:

   sudo pcs status
   

جمع‌بندی

مدل Active/Passive یک روش ساده و کارآمد برای پیاده‌سازی کلاسترهای High Availability است. در این مدل، یک گره به‌عنوان گره فعال عمل می‌کند و گره‌های پشتیبان تنها در صورت خرابی گره فعال وارد عمل می‌شوند. این مدل مزایای زیادی از جمله سادگی پیاده‌سازی و کاهش هزینه‌ها دارد، اما در عین حال معایبی مانند استفاده ناکارآمد از منابع و تأخیر در فرآیند Failover نیز دارد. با استفاده از ابزارهایی مانند Pacemaker در لینوکس، می‌توان این مدل را به‌طور مؤثر پیاده‌سازی کرد و اطمینان حاصل کرد که سیستم در برابر خرابی‌ها مقاوم است.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”Active/Active: هر دو گره به طور همزمان فعال هستند و منابع را مدیریت می‌کنند” subtitle=”توضیحات کامل”]مدل Active/Active یکی از روش‌های پیشرفته‌تر برای پیاده‌سازی کلاسترهای High Availability (HA) است. در این مدل، برخلاف مدل Active/Passive که فقط یک گره به‌طور فعال در حال پردازش است، هر دو گره به‌طور همزمان فعال بوده و منابع را مدیریت می‌کنند. این مدل به‌طور گسترده برای افزایش تحمل خطا و بهبود مقیاس‌پذیری استفاده می‌شود. در این قسمت، به بررسی نحوه عملکرد، مزایا، معایب و نحوه پیکربندی مدل Active/Active خواهیم پرداخت.

1. نحوه عملکرد مدل Active/Active

در مدل Active/Active، هر دو گره به‌طور همزمان منابع را مدیریت می‌کنند و قادرند درخواست‌ها را به‌طور موازی پردازش کنند. در این مدل، معمولاً بار کاری (Workload) به‌طور مساوی یا براساس یک الگوریتم توزیع بار (Load Balancing) بین گره‌ها تقسیم می‌شود. این مدل نه تنها باعث افزایش تحمل خطا می‌شود، بلکه می‌تواند مقیاس‌پذیری سیستم را نیز بهبود بخشد.

ویژگی‌های مدل Active/Active:

• عملکرد همزمان: هر دو گره به‌طور همزمان فعال هستند و درخواست‌ها و منابع را به‌طور موازی پردازش می‌کنند.
• توزیع بار: بار کاری به‌طور مساوی یا براساس یک استراتژی خاص بین گره‌ها توزیع می‌شود. این توزیع بار می‌تواند به‌صورت دستی یا خودکار باشد.
• پایداری بیشتر: اگر یکی از گره‌ها دچار خرابی شود، گره دیگر به‌طور خودکار ادامه خواهد داد و بار کاری را بر عهده می‌گیرد، بدون اینکه تاثیری بر عملکرد سیستم داشته باشد.
• مقیاس‌پذیری بالا: از آنجا که هر دو گره به‌طور همزمان مشغول پردازش هستند، می‌توان به‌راحتی با اضافه کردن گره‌های بیشتر به سیستم مقیاس‌پذیری را افزایش داد.

نحوه کارکرد در صورت خرابی:

• خرابی یک گره: اگر یکی از گره‌ها دچار خرابی شود، گره دیگر به‌طور خودکار ادامه خواهد داد و بار کاری گره خراب‌شده را بر عهده می‌گیرد. چون هر دو گره به‌طور همزمان فعال هستند، این فرآیند به سرعت انجام می‌شود و هیچ تأخیر قابل توجهی ایجاد نمی‌شود.
• همگام‌سازی داده‌ها: یکی از چالش‌های مدل Active/Active، همگام‌سازی داده‌ها بین گره‌ها است. برای اینکه هر گره از آخرین وضعیت داده‌ها مطلع باشد، باید از مکانیزم‌های همگام‌سازی داده‌ها استفاده شود تا داده‌ها در هر دو گره به‌روز باقی بمانند.

2. مزایای مدل Active/Active

• افزایش تحمل خطا (Fault Tolerance): در صورت خرابی یکی از گره‌ها، گره دیگر بدون هیچ‌گونه وقفه‌ای به پردازش ادامه می‌دهد.
• مقیاس‌پذیری بهتر: مدل Active/Active به راحتی قابل گسترش است. با اضافه کردن گره‌های بیشتر به کلاستر، می‌توان مقیاس سیستم را به‌طور عمودی یا افقی افزایش داد.
• بهبود عملکرد: چون هر دو گره همزمان مشغول پردازش درخواست‌ها هستند، زمان پاسخ‌دهی به کاربران و ظرفیت پردازش افزایش می‌یابد.
• استفاده بهینه از منابع: در این مدل، تمامی منابع گره‌ها به‌طور فعال استفاده می‌شوند و هیچ‌گونه منابع اضافی هدر نمی‌رود.

3. معایب مدل Active/Active

• پیچیدگی همگام‌سازی داده‌ها: یکی از معایب اصلی مدل Active/Active، نیاز به همگام‌سازی داده‌ها بین گره‌ها است. اگر گره‌ها نتوانند به‌طور مؤثر داده‌ها را همگام‌سازی کنند، این امر می‌تواند منجر به ناسازگاری داده‌ها و مشکلات دیگر شود.
• مدیریت پیچیده: مدیریت یک کلاستر Active/Active پیچیده‌تر از مدل Active/Passive است زیرا نیاز به نظارت و همگام‌سازی بیشتر دارد.
• هزینه‌های بالاتر: به دلیل نیاز به منابع بیشتر برای پردازش همزمان، این مدل ممکن است هزینه‌های بالاتری نسبت به مدل‌های دیگر داشته باشد.

4. پیاده‌سازی مدل Active/Active در لینوکس با استفاده از Pacemaker

در لینوکس، برای پیاده‌سازی کلاسترهای Active/Active می‌توان از ابزار Pacemaker استفاده کرد. Pacemaker به‌عنوان یک ابزار مدیریت کلاستر، قادر است منابع را بین گره‌ها توزیع کرده و از همگام‌سازی داده‌ها اطمینان حاصل کند.

مراحل پیکربندی Active/Active با استفاده از Pacemaker

1. نصب Pacemaker و Corosync:ابتدا باید Pacemaker و Corosync را روی هر دو گره نصب کنیم:

   sudo apt-get install pacemaker corosync
   

2. پیکربندی Corosync:فایل پیکربندی Corosync باید به‌گونه‌ای تنظیم شود که به هر دو گره اجازه دهد که به‌طور همزمان منابع را مدیریت کنند. فایل /etc/corosync/corosync.conf به‌صورت زیر تنظیم می‌شود:

   totem {
       version: 2
       cluster_name: mycluster
       secauth: off
       interface {
           ringnumber: 0
           bindnetaddr: 192.168.1.0
           mcastaddr: 239.255.1.1
           mcastport: 5405
       }
   }
   

3. راه‌اندازی Pacemaker:برای شروع کار، Pacemaker باید روی هر دو گره راه‌اندازی شود:

   sudo systemctl start pacemaker
   sudo systemctl enable pacemaker
   

4. تعریف منابع (Resources):در این مرحله، منابعی که باید بین گره‌ها تقسیم شوند را تعریف می‌کنیم. به‌عنوان مثال، فرض کنید که یک سرویس Apache داریم که باید به‌طور Active/Active در هر دو گره فعال باشد:

   sudo pcs resource create apache-service ocf:heartbeat:apache op monitor interval=30s
   

5. توزیع بار (Load Balancing):برای توزیع بار بین گره‌ها، می‌توان از یک Load Balancer استفاده کرد. می‌توانیم یک IP مجازی به منابع Apache اختصاص دهیم تا درخواست‌ها بین گره‌ها توزیع شوند:

   sudo pcs resource create virtual-ip IPaddr2 ip=192.168.1.100 op monitor interval=30s
   

6. بررسی وضعیت کلاستر:پس از پیکربندی، می‌توانیم وضعیت کلاستر را بررسی کرده و از عملکرد صحیح آن مطمئن شویم:

   sudo pcs status
   

جمع‌بندی

مدل Active/Active یکی از روش‌های پیشرفته برای پیاده‌سازی کلاسترهای High Availability است که در آن هر دو گره به‌طور همزمان فعال هستند و منابع را مدیریت می‌کنند. این مدل مزایای زیادی از جمله افزایش تحمل خطا، مقیاس‌پذیری بالا و استفاده بهینه از منابع دارد، اما در عین حال با چالش‌هایی مانند پیچیدگی همگام‌سازی داده‌ها و نیاز به مدیریت دقیق‌تر مواجه است. با استفاده از ابزارهایی مانند Pacemaker، می‌توان مدل Active/Active را به‌طور مؤثر در لینوکس پیاده‌سازی کرده و از عملکرد بهینه سیستم در برابر خرابی‌ها اطمینان حاصل کرد.[/cdb_course_lesson][cdb_course_lesson title=”فصل 4. نحوه ارتباط کلاسترها و اجزای آنها”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”توضیح روش‌های ارتباطی بین گره‌ها مانند Corosync و شبکه‌های ارتباطی” subtitle=”توضیحات کامل”]در کلاسترهای High Availability (HA)، ارتباط بین گره‌ها (Nodes) اهمیت بسیار زیادی دارد. این ارتباط به‌عنوان بخشی از زیرساخت، تضمین می‌کند که تمام گره‌ها بتوانند به‌طور مؤثر و هماهنگ با یکدیگر کار کنند. یکی از مهم‌ترین ابزارهایی که برای پیاده‌سازی ارتباطات میان گره‌ها استفاده می‌شود، Corosync است. در این بخش، به بررسی روش‌های مختلف ارتباطی بین گره‌ها، از جمله Corosync و شبکه‌های ارتباطی، خواهیم پرداخت.

1. Corosync: ابزار ارتباطی اصلی برای کلاسترهای HA

Corosync یکی از ابزارهای کلیدی در مدیریت کلاسترهای HA است. این ابزار برای ارائه خدماتی مانند توزیع پیام‌ها، اطلاع‌رسانی تغییرات وضعیت، و همگام‌سازی داده‌ها بین گره‌ها استفاده می‌شود. Corosync به‌عنوان یک سیستم پیام‌رسان در زیرساخت کلاستر عمل می‌کند و نقش اساسی در ارتباط میان گره‌ها دارد.

ویژگی‌های Corosync:

• توزیع پیام‌ها: Corosync برای ارسال پیام‌ها بین گره‌ها استفاده می‌شود. این پیام‌ها می‌توانند شامل اطلاعات مربوط به وضعیت گره‌ها، منابع و درخواست‌ها باشند.
• همگام‌سازی وضعیت: Corosync تضمین می‌کند که وضعیت گره‌ها در کلاستر همگام باشد. اگر تغییراتی در وضعیت یکی از گره‌ها رخ دهد، این تغییرات به سایر گره‌ها اطلاع داده می‌شود.
• پشتیبانی از پیام‌رسانی چندگانه: Corosync از پروتکل‌های شبکه‌های چندگانه پشتیبانی می‌کند، که امکان ارسال پیام‌ها به گره‌های مختلف در شبکه را فراهم می‌آورد.
• نظارت بر ارتباطات: Corosync به‌طور مداوم ارتباطات بین گره‌ها را نظارت می‌کند و در صورت بروز مشکلات در ارتباطات، به سرعت گره مشکل‌دار را از کلاستر جدا می‌کند.

نحوه کار Corosync:

Corosync از یک پروتکل به نام Totem برای ارسال پیام‌ها بین گره‌ها استفاده می‌کند. در این پروتکل، گره‌ها در یک حلقه بسته قرار دارند و هر کدام به‌طور دوره‌ای پیام‌هایی به گره‌های دیگر ارسال می‌کنند تا از سلامت ارتباطات اطمینان حاصل کنند. در صورت بروز خرابی در ارتباطات، سیستم به‌طور خودکار مکانیزم‌های اصلاحی را اعمال می‌کند.

پیکربندی Corosync معمولاً در فایل /etc/corosync/corosync.conf انجام می‌شود و باید به‌گونه‌ای تنظیم شود که گره‌ها بتوانند از طریق شبکه به یکدیگر متصل شوند.

2. شبکه‌های ارتباطی در کلاسترهای HA

در کلاسترهای HA، شبکه‌های ارتباطی نقش مهمی در تضمین دسترس‌پذیری و هماهنگی گره‌ها دارند. این شبکه‌ها باید دارای ویژگی‌هایی مانند پهنای باند بالا، تاخیر پایین، و پایداری باشند تا از خرابی و از دست رفتن اطلاعات جلوگیری کنند.

انواع شبکه‌های ارتباطی برای کلاسترهای HA:

• شبکه‌های محلی (LAN): یکی از رایج‌ترین روش‌های ارتباطی بین گره‌ها استفاده از شبکه‌های محلی است. در این شبکه‌ها، گره‌ها از طریق سوئیچ‌ها و روترها به یکدیگر متصل می‌شوند. این نوع شبکه‌ها معمولاً تاخیر کمی دارند و برای کلاسترهای HA مناسب هستند.
• شبکه‌های اختصاصی: در برخی از سیستم‌ها، از شبکه‌های اختصاصی برای ارتباط میان گره‌ها استفاده می‌شود. این شبکه‌ها به‌طور خاص برای انتقال داده‌های بین گره‌های کلاستر طراحی شده‌اند و تضمین می‌کنند که تنها گره‌های کلاستر به یکدیگر متصل هستند.
• شبکه‌های WAN: در کلاسترهایی که گره‌ها در موقعیت‌های جغرافیایی مختلف قرار دارند، از شبکه‌های WAN (Wide Area Network) استفاده می‌شود. این نوع شبکه‌ها معمولاً هزینه‌برتر هستند و ممکن است تاخیر بالاتری داشته باشند، بنابراین باید دقت بیشتری در طراحی و پیکربندی انجام شود.

نحوه طراحی شبکه‌های ارتباطی:

برای اطمینان از عملکرد بهینه، طراحی شبکه‌های ارتباطی در کلاسترهای HA باید به‌گونه‌ای باشد که پهنای باند کافی، تاخیر کم، و پایداری بالا را فراهم کند. این موارد شامل موارد زیر است:

• تخصیص شبکه برای هر نوع ترافیک: شبکه‌های ارتباطی باید به‌طور جداگانه برای ترافیک کنترل (مثلاً پیام‌های Corosync)، ترافیک داده (مانند انتقال فایل‌ها)، و ترافیک منابع مشترک (مثل IPهای مجازی) پیکربندی شوند.
• استفاده از پروتکل‌های مسیریابی و سوئیچینگ بهینه: برای بهبود عملکرد شبکه، استفاده از پروتکل‌های مسیریابی بهینه مانند OSPF و BGP می‌تواند مفید باشد.
• استفاده از شبکه‌های بازسازی‌شونده: برای اطمینان از دسترس‌پذیری پایدار، طراحی شبکه باید شامل ویژگی‌های بازسازی (failover) باشد که در صورت خرابی شبکه، ترافیک به شبکه‌های پشتیبان منتقل شود.

3. ارتباط Corosync با سایر ابزارهای کلاستر

Corosync معمولاً به‌عنوان یک ابزار ارتباطی در کنار سایر ابزارهای مدیریت کلاستر مانند Pacemaker و CRM (Cluster Resource Manager) استفاده می‌شود. در این حالت، Corosync به‌عنوان سیستم پیام‌رسان برای توزیع وضعیت منابع و اطلاع‌رسانی به گره‌ها عمل می‌کند، در حالی که Pacemaker وظیفه مدیریت منابع و فرآیندهای کلاستر را به عهده دارد.

پیاده‌سازی Corosync و Pacemaker:

• پیکربندی فایل Corosync:در فایل /etc/corosync/corosync.conf، تنظیمات مربوط به شبکه و توپولوژی کلاستر انجام می‌شود. یک پیکربندی اولیه به این شکل خواهد بود:

  totem {
      version: 2
      cluster_name: mycluster
      secauth: on
      interface {
          ringnumber: 0
          bindnetaddr: 192.168.1.0
          mcastaddr: 239.255.1.1
          mcastport: 5405
      }
  }
  

• راه‌اندازی Pacemaker:برای راه‌اندازی Pacemaker، از دستورات زیر استفاده می‌شود:

  sudo systemctl start pacemaker
  sudo systemctl enable pacemaker
  

  Pacemaker از داده‌های ارسال شده از طریق Corosync استفاده می‌کند تا وضعیت منابع را در کلاستر نظارت کرده و در صورت نیاز به انتقال منابع یا Failover، اقدام کند.

جمع‌بندی

Corosync به‌عنوان یکی از ابزارهای اصلی برای ارتباط بین گره‌ها در کلاسترهای High Availability، نقش حیاتی در ارسال پیام‌ها، همگام‌سازی وضعیت گره‌ها و نظارت بر ارتباطات دارد. شبکه‌های ارتباطی مورد استفاده در این کلاسترها باید با ویژگی‌هایی مانند پهنای باند بالا، تاخیر کم، و پایداری طراحی شوند تا عملکرد بهینه‌ای داشته باشند. در نهایت، Corosync در کنار ابزارهایی مانند Pacemaker به‌طور مؤثر منابع کلاستر را مدیریت می‌کند و تضمین می‌کند که سیستم در برابر خرابی‌ها پایدار و دسترس‌پذیر باقی بماند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”معرفی Quorum برای مدیریت تصمیمات در شرایط بحرانی” subtitle=”توضیحات کامل”]در کلاسترهای High Availability (HA)، یک مفهوم بسیار حیاتی برای مدیریت و هماهنگی تصمیمات در شرایط بحرانی، Quorum است. Quorum به سیستمی اطلاق می‌شود که تعداد حداقلی از گره‌ها را برای پذیرش و اجرای تصمیمات در مورد وضعیت کلاستر یا منابع مورد نیاز است. در واقع، Quorum به کلاسترها اجازه می‌دهد تا از بروز تصمیمات نادرست و مشکلات ناشی از تقسیم کلاستر به دو بخش یا بیشتر جلوگیری کنند.

1. مفهوم Quorum

Quorum به حداقل تعداد گره‌های حاضر در کلاستر اشاره دارد که باید در تصمیم‌گیری‌ها شرکت کنند تا تصمیمات به‌طور معتبر و درست گرفته شوند. این سیستم از وقوع Split Brain جلوگیری می‌کند، که وضعیتی است که در آن گره‌های کلاستر به دلیل قطع ارتباط با یکدیگر تصور می‌کنند که در حال کار به‌تنهایی هستند و هر کدام تصمیمات متفاوتی را برای منابع می‌گیرند.

Split Brain زمانی رخ می‌دهد که چندین گره در کلاستر ارتباط خود را با بقیه گره‌ها قطع کرده و هر یک از این بخش‌ها سعی می‌کند منابع را مدیریت کند. این امر می‌تواند منجر به مشکلاتی از جمله دسترسی همزمان به منابع و آسیب به داده‌ها شود.

2. نحوه کار Quorum

برای جلوگیری از Split Brain و مشکلات مشابه، کلاسترهای HA به‌طور معمول از سیستم‌های Quorum استفاده می‌کنند. سیستم Quorum تصمیمات را بر اساس تعداد گره‌ها می‌گیرد و برای این منظور از یکی از روش‌های زیر استفاده می‌کند:

• نصف به‌علاوه یک: این روش معمولاً به‌عنوان رایج‌ترین روش در کلاسترهای HA شناخته می‌شود. در این روش، برای داشتن Quorum، باید حداقل یک گره بیشتر از نصف گره‌ها در کلاستر حاضر و فعال باشند. اگر این شرط رعایت نشود، هیچ‌یک از گره‌ها قادر به اجرای تصمیمات نخواهند بود.
• وزن‌دهی به گره‌ها: در برخی از کلاسترها، به هر گره یک وزن (Weight) داده می‌شود که تعیین می‌کند که چقدر از قدرت تصمیم‌گیری برخوردار است. در این حالت، کلاستر نیاز دارد که مجموع وزن گره‌های حاضر از یک حد مشخصی بیشتر باشد تا تصمیمات معتبر باشند.

3. حضور Quorum در شرایط بحرانی

در شرایط بحرانی که ارتباطات گره‌ها دچار اختلال می‌شود، سیستم Quorum به کلاستر کمک می‌کند تا از بروز مشکلات جدی جلوگیری کند. به طور مثال:

• در زمان قطع ارتباط گره‌ها: اگر تعدادی از گره‌ها از بقیه جدا شوند، سیستم Quorum فقط اجازه می‌دهد که گره‌های با اکثریت حاضر اقدام به مدیریت منابع کنند.
• حفظ صحت داده‌ها: با استفاده از Quorum، از بروز دسترسی همزمان به منابع جلوگیری می‌شود. در صورت بروز قطع ارتباط، کلاستر به‌طور خودکار تصمیم می‌گیرد که کدام گره‌ها معتبر هستند و اجازه نمی‌دهد که گره‌های غیرفعال تصمیمات اشتباه بگیرند.

در واقع، Quorum نقش تعیین‌کننده‌ای در جلوگیری از تغییرات اشتباه در منابع و اطمینان از حفظ یکپارچگی داده‌ها ایفا می‌کند.

4. پیکربندی Quorum در لینوکس

برای استفاده از Quorum در کلاسترهای لینوکسی، معمولاً از ابزارهای مدیریت کلاستر مانند Pacemaker و Corosync استفاده می‌شود. یکی از پیکربندی‌هایی که برای تنظیم Quorum در کلاسترها ضروری است، تنظیم مقدار no-quorum-policy در Pacemaker است.

پیکربندی Quorum در Pacemaker:

برای پیکربندی Quorum در Pacemaker، شما می‌توانید از دستور زیر استفاده کنید:

sudo pcs property set no-quorum-policy=ignore

در این دستور، no-quorum-policy به یکی از سه حالت قابل تنظیم است:

• ignore: در صورت عدم وجود Quorum، کلاستر ادامه می‌دهد و تصمیمات را اعمال می‌کند.
• freeze: در صورت عدم وجود Quorum، تغییرات متوقف می‌شوند و هیچ‌گونه عملیات جدیدی انجام نمی‌شود.
• demote: در صورت عدم وجود Quorum، گره‌ها به حالت غیرفعال تبدیل می‌شوند.

5. مزایای استفاده از Quorum

استفاده از Quorum در کلاسترهای HA مزایای زیادی دارد که شامل موارد زیر است:

• جلوگیری از Split Brain: Quorum از تصمیم‌گیری‌های مستقل گره‌ها در وضعیت قطع ارتباط جلوگیری می‌کند.
• افزایش پایداری کلاستر: با ایجاد تصمیم‌گیری هماهنگ، کلاستر می‌تواند در شرایط بحرانی و خطاها به‌طور مؤثر عمل کند.
• حفظ یکپارچگی داده‌ها: با جلوگیری از دسترسی همزمان به منابع، Quorum اطمینان می‌دهد که منابع به‌طور یکپارچه و درست مدیریت شوند.

6. چالش‌ها و محدودیت‌های Quorum

در حالی که Quorum ابزاری قدرتمند است، ممکن است در شرایط خاص چالش‌هایی به همراه داشته باشد:

• راه‌اندازی گره‌های جدید: در برخی موارد، اضافه کردن گره‌های جدید به کلاستر با مشکل مواجه می‌شود. برای حل این مشکل، باید پیکربندی Quorum به‌طور دقیق انجام شود.
• عملکرد در کلاسترهای بزرگ: در کلاسترهای بسیار بزرگ، مکانیزم‌های Quorum ممکن است نیاز به پیکربندی‌های پیچیده‌تری داشته باشند تا بتوانند به‌طور مؤثر عمل کنند.

جمع‌بندی

Quorum یک ابزار حیاتی در مدیریت تصمیمات در کلاسترهای High Availability است که از بروز مشکلاتی مانند Split Brain جلوگیری می‌کند و تضمین می‌کند که کلاستر تنها در صورت حضور گره‌های کافی در تصمیمات مشارکت کند. این سیستم با استفاده از روش‌هایی مانند نصف به‌علاوه یک یا وزن‌دهی به گره‌ها، از صحت و یکپارچگی تصمیمات در شرایط بحرانی اطمینان حاصل می‌کند. با پیکربندی مناسب Quorum، کلاسترهای HA می‌توانند عملکرد پایدار و قابل اعتمادی در برابر خرابی‌ها داشته باشند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 5. ابزارهای مدیریت کلاستر در لینوکس”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”معرفی ابزارهایی چون Pacemaker و Corosync برای مدیریت منابع و ارتباطات گره‌ها” subtitle=”توضیحات کامل”]در کلاسترهای High Availability (HA) در لینوکس، ابزارهایی مانند Pacemaker و Corosync نقش‌های اساسی در مدیریت منابع، ارتباطات گره‌ها، و هماهنگی تصمیمات در شرایط مختلف ایفا می‌کنند. این ابزارها به‌طور مشترک به کلاسترهای HA اجازه می‌دهند که منابع و گره‌ها را به‌طور هوشمندانه مدیریت کنند و از بروز مشکلات مانند دسترسی همزمان به منابع جلوگیری نمایند.

1. Corosync: مدیریت ارتباطات گره‌ها

Corosync یکی از ابزارهای مهم در کلاسترهای HA است که به‌طور ویژه برای مدیریت ارتباطات بین گره‌های کلاستر طراحی شده است. این ابزار مسئولیت برقراری ارتباط امن و پایدار بین گره‌ها را بر عهده دارد و از انتقال اطلاعات حساس و همزمانی تصمیمات در گره‌های مختلف اطمینان می‌دهد.

ویژگی‌های اصلی Corosync:

• مدیریت ارتباطات: Corosync مسئول برقراری ارتباطات درون کلاستر است. این ابزار به گره‌ها اجازه می‌دهد تا وضعیت یکدیگر را شناسایی کرده و اطلاعات مربوط به تغییرات در منابع را به‌سرعت تبادل کنند.
• مکانیزم Quorum: Corosync از مفهوم Quorum برای جلوگیری از وقوع Split Brain استفاده می‌کند. این ابزار تصمیمات کلاستر را فقط زمانی معتبر می‌سازد که تعداد کافی از گره‌ها به‌طور همزمان برای یک تصمیم موجود باشند.
• پیکربندی خودکار: Corosync امکان پیکربندی خودکار و توزیع‌شده را فراهم می‌کند، به طوری که نیاز به تنظیمات دستی زیادی ندارد و می‌تواند در کلاسترهای با تعداد گره‌های بالا به‌طور مؤثر عمل کند.

پیکربندی Corosync:

برای راه‌اندازی Corosync در یک کلاستر لینوکس، شما باید فایل پیکربندی corosync.conf را در مسیر زیر ویرایش کنید:

/etc/corosync/corosync.conf

در این فایل، شما می‌توانید تنظیمات مربوط به شبکه ارتباطی و ویژگی‌های Quorum را اعمال کنید.

2. Pacemaker: مدیریت منابع و خدمات

در کنار Corosync، Pacemaker یکی از مهم‌ترین ابزارهای مدیریتی در کلاسترهای HA است. Pacemaker مسئولیت مدیریت منابع و خدمات را در کلاستر بر عهده دارد و به‌طور خودکار منابع را بین گره‌ها جابجا می‌کند تا اطمینان حاصل شود که هیچ‌یک از منابع در صورت خرابی یا مشکلات دیگر از دست نروند.

ویژگی‌های اصلی Pacemaker:

• مدیریت منابع: Pacemaker منابع مختلف مانند سرویس‌ها، IP‌ها، و دیسک‌ها را بین گره‌های کلاستر مدیریت می‌کند. این ابزار می‌تواند منابع را به‌طور خودکار بین گره‌ها جابجا کند و در صورت خرابی یک گره، منابع را به گره‌های سالم انتقال دهد.
• مدیریت Failover: Pacemaker در صورت خرابی یک گره یا منبع، به‌طور خودکار منابع را به گره دیگر منتقل می‌کند. این مکانیزم Failover یا انتقال منابع در صورت خرابی نامیده می‌شود.
• نظارت بر وضعیت گره‌ها: Pacemaker وضعیت گره‌ها را به‌طور مداوم بررسی می‌کند و به‌محض شناسایی خرابی یا مشکل در یک گره، اقدامات لازم را برای حفظ دسترس‌پذیری سیستم انجام می‌دهد.

پیکربندی Pacemaker:

برای مدیریت منابع و پیکربندی Failover در Pacemaker، از دستور pcs استفاده می‌شود. به‌طور مثال، برای تنظیم Quorum در Pacemaker، می‌توانید دستور زیر را اجرا کنید:

sudo pcs property set no-quorum-policy=freeze

این دستور مشخص می‌کند که در صورت عدم وجود Quorum، هیچ‌گونه تغییر جدیدی در کلاستر ایجاد نشود و گره‌ها به حالت توقف درآیند تا از بروز مشکلات جلوگیری شود.

3. نحوه همکاری Corosync و Pacemaker

در کلاسترهای HA لینوکس، Corosync و Pacemaker به‌طور همزمان و هماهنگ عمل می‌کنند:

• Corosync مسئول برقراری ارتباطات بین گره‌ها و مدیریت وضعیت Quorum است.
• Pacemaker وظیفه مدیریت منابع و اطمینان از دسترس‌پذیری منابع را در صورت خرابی گره‌ها بر عهده دارد.

در واقع، Corosync ارتباطات بین گره‌ها را فراهم می‌کند و اطلاعات وضعیت گره‌ها را برای Pacemaker ارسال می‌کند. سپس Pacemaker منابع را بر اساس اطلاعات دریافت‌شده از Corosync مدیریت کرده و در صورت لزوم، منابع را به گره‌های دیگر انتقال می‌دهد.

4. مزایای استفاده از Pacemaker و Corosync در کلاسترهای HA

استفاده از Pacemaker و Corosync در کلاسترهای HA مزایای زیادی دارد که به شرح زیر است:

• افزایش دسترس‌پذیری: با استفاده از این ابزارها، کلاستر قادر است تا در صورت خرابی یک گره یا منبع، به‌طور خودکار به گره‌های سالم منتقل شود و از وقفه در خدمات جلوگیری کند.
• مدیریت خودکار منابع: Pacemaker می‌تواند منابع مختلف را به‌طور خودکار مدیریت و جابجا کند، به طوری که نیازی به مداخله دستی در بیشتر مواقع نیست.
• مطمئن از وضعیت ارتباطات: Corosync از پایداری ارتباطات بین گره‌ها اطمینان حاصل می‌کند و از بروز مشکلات ناشی از قطع ارتباط جلوگیری می‌کند.

جمع‌بندی

ابزارهای Pacemaker و Corosync در کلاسترهای High Availability (HA) لینوکس برای مدیریت ارتباطات گره‌ها، منابع، و تصمیمات در شرایط بحرانی بسیار مهم هستند. Corosync مسئول ارتباطات و مدیریت Quorum است، در حالی که Pacemaker منابع و خدمات را در کلاستر مدیریت می‌کند و از بروز مشکلاتی مانند Split Brain و خرابی منابع جلوگیری می‌کند. این ابزارها با هم‌افزایی عملکرد خود، از پایداری و دسترس‌پذیری کلاسترهای HA اطمینان می‌دهند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”پیکربندی ابتدایی کلاستر با استفاده از Pacemaker و Corosync” subtitle=”توضیحات کامل”]در این بخش، نحوه پیکربندی ابتدایی کلاستر High Availability (HA) با استفاده از ابزارهای Pacemaker و Corosync توضیح داده می‌شود. این پیکربندی‌ها به شما این امکان را می‌دهند که گره‌ها را به‌طور مؤثر با یکدیگر هماهنگ کرده و منابع را مدیریت کنید.

برای ایجاد یک کلاستر ابتدایی HA در لینوکس، به طور معمول باید موارد زیر را انجام دهید:

1. نصب ابزارهای Pacemaker و Corosync
2. پیکربندی Corosync برای ارتباطات گره‌ها
3. پیکربندی Pacemaker برای مدیریت منابع

1. نصب ابزارهای Pacemaker و Corosync

ابتدا باید Pacemaker و Corosync را بر روی تمام گره‌های موجود در کلاستر نصب کنید. این ابزارها در بیشتر توزیع‌های لینوکس قابل نصب هستند.

برای نصب ابزارها در توزیع‌های Debian یا Ubuntu از دستورات زیر استفاده کنید:

sudo apt update
sudo apt install pacemaker corosync pcs

در توزیع‌های CentOS یا RHEL از دستورات زیر استفاده کنید:

sudo yum install pacemaker corosync pcs

2. پیکربندی Corosync برای ارتباطات گره‌ها

پس از نصب ابزارها، باید فایل پیکربندی Corosync را ویرایش کنید تا ارتباطات بین گره‌ها به درستی برقرار شود. این پیکربندی معمولاً در مسیر زیر قرار دارد:

/etc/corosync/corosync.conf

در این فایل، باید تنظیمات مربوط به ارتباطات شبکه، روش‌های شناسایی گره‌ها و ویژگی‌های Quorum را مشخص کنید. به عنوان مثال، پیکربندی ابتدایی Corosync به شکل زیر خواهد بود:

totem {
    version: 2
    cluster_name: mycluster
    transport: udpu
    interface {
        ringnumber: 0
        bindnetaddr: 192.168.1.0
        mcastaddr: 226.94.1.1
        mcastport: 5405
    }
}

logging {
    to_stderr: yes
    to_logfile: yes
    logfile: /var/log/corosync/corosync.log
    debug: off
    timestamp: on
}

quorum {
    provider: corosync_votequorum
}

در این پیکربندی:

• bindnetaddr: آدرس IP شبکه‌ای که گره‌ها به آن متصل خواهند شد.
• mcastaddr: آدرس پخش چندگانه برای ارتباطات گره‌ها.
• ringnumber: شماره حلقه (می‌تواند به عنوان چندین رابط شبکه استفاده شود).

3. پیکربندی Pacemaker برای مدیریت منابع

پس از پیکربندی Corosync، مرحله بعدی تنظیم Pacemaker برای مدیریت منابع است. در این مرحله، Pacemaker مسئولیت منابع را در کلاستر بر عهده خواهد گرفت و به طور خودکار منابع را در صورت خرابی گره‌ها به گره‌های سالم منتقل می‌کند.

برای شروع، باید PCS را فعال کرده و سپس از آن برای راه‌اندازی Pacemaker استفاده کنید. ابتدا باید PCS را روی گره‌ها فعال کنید. دستور زیر را اجرا کنید:

sudo systemctl enable pcsd
sudo systemctl start pcsd

سپس باید رمز عبور مشترک برای کلاستر تنظیم شود. این کار را با استفاده از دستور زیر انجام دهید:

sudo pcs cluster auth node1 node2 -u hacluster -p password

در این دستور:

• node1 و node2 به نام گره‌های موجود در کلاستر شما اشاره دارند.
• hacluster نام کاربری پیش‌فرض برای دسترسی به ابزارهای کلاستر است.
• password رمز عبور مشترک برای گره‌ها است.

پس از تأیید اعتبار، می‌توانید کلاستر را راه‌اندازی کنید:

sudo pcs cluster setup --name mycluster node1 node2

برای شروع کلاستر و راه‌اندازی آن، از دستور زیر استفاده کنید:

sudo pcs cluster start --all

4. بررسی وضعیت کلاستر

برای بررسی وضعیت کلاستر و اطمینان از این که همه‌چیز به درستی پیکربندی شده است، می‌توانید دستور زیر را اجرا کنید:

sudo pcs status

این دستور اطلاعاتی مانند وضعیت گره‌ها، منابع فعال و وضعیت کلی کلاستر را نمایش می‌دهد.

5. پیکربندی منابع در Pacemaker

برای مدیریت منابع مختلف مانند IP‌های مجازی، سرویس‌ها یا فایل‌ها در Pacemaker، باید منابع را تعریف کنید. به عنوان مثال، برای اضافه کردن یک IP مجازی به کلاستر، دستور زیر را اجرا کنید:

sudo pcs resource create VirtualIP IPaddr2 ip=192.168.1.100 cidr_netmask=24 op monitor interval=30s

در این دستور:

• VirtualIP نام منبع است.
• IPaddr2 نوع منبع است که برای ایجاد آدرس IP مجازی استفاده می‌شود.
• ip=192.168.1.100 آدرس IP مجازی است.
• cidr_netmask=24 زیرشبکه مرتبط با IP است.
• op monitor interval=30s نظارت بر وضعیت این منبع هر 30 ثانیه یک‌بار انجام می‌شود.

6. پیکربندی Failover در Pacemaker

برای پیکربندی مکانیزم Failover به‌طوری که منابع به‌طور خودکار در صورت خرابی گره‌ها منتقل شوند، باید منابع را به گره‌ها اختصاص دهید. برای این کار از دستور زیر استفاده می‌شود:

sudo pcs constraint location VirtualIP prefers node1=INFINITY

این دستور مشخص می‌کند که منبع VirtualIP ابتدا در node1 اجرا شود. اگر گره node1 دچار مشکل شود، منبع به‌طور خودکار به گره دیگر منتقل می‌شود.

جمع‌بندی

در این بخش، نحوه پیکربندی ابتدایی کلاستر High Availability (HA) با استفاده از ابزارهای Pacemaker و Corosync را بررسی کردیم. مراحل شامل نصب ابزارها، پیکربندی Corosync برای برقراری ارتباطات گره‌ها، تنظیم Pacemaker برای مدیریت منابع، و پیکربندی مکانیزم‌های Failover و Quorum بود. این تنظیمات پایه‌ای برای راه‌اندازی یک کلاستر HA است که می‌تواند در محیط‌های تولیدی به کار گرفته شود.[/cdb_course_lesson][cdb_course_lesson title=”فصل 6. پیکربندی اولیه یک کلاستر HA”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”نصب و راه‌اندازی کلاستر ساده با دو گره” subtitle=”توضیحات کامل”]برای راه‌اندازی یک کلاستر ساده High Availability (HA) با استفاده از Pacemaker و Corosync در لینوکس، باید مراحل نصب، پیکربندی، و بررسی وضعیت گره‌ها را به‌طور دقیق انجام دهید. در این راهنما، از دو گره برای ایجاد کلاستر استفاده خواهیم کرد.

مراحل نصب و راه‌اندازی:

1. نصب Pacemaker و Corosync
2. پیکربندی فایل‌های Corosync
3. پیکربندی کلاستر با استفاده از PCS
4. راه‌اندازی کلاستر و بررسی وضعیت
5. پیکربندی منابع برای مدیریت

1. نصب Pacemaker و Corosync

ابتدا باید بسته‌های Pacemaker و Corosync را بر روی هر دو گره نصب کنید. برای نصب این بسته‌ها از دستور زیر استفاده کنید.

برای توزیع‌های Debian یا Ubuntu:

sudo apt update
sudo apt install pacemaker corosync pcs

برای توزیع‌های CentOS یا RHEL:

sudo yum install pacemaker corosync pcs

2. پیکربندی فایل‌های Corosync

پس از نصب، باید پیکربندی ارتباطات گره‌ها را در فایل Corosync تنظیم کنید. این فایل معمولاً در مسیر زیر قرار دارد:

/etc/corosync/corosync.conf

در این فایل باید مواردی مانند آدرس‌های شبکه، ارتباطات حلقه‌ها و تنظیمات Quorum را پیکربندی کنید. یک پیکربندی ابتدایی به شکل زیر خواهد بود:

totem {
    version: 2
    cluster_name: mycluster
    transport: udpu
    interface {
        ringnumber: 0
        bindnetaddr: 192.168.1.0  # آدرس شبکه گره‌ها
        mcastaddr: 226.94.1.1     # آدرس پخش چندگانه
        mcastport: 5405
    }
}

logging {
    to_stderr: yes
    to_logfile: yes
    logfile: /var/log/corosync/corosync.log
    debug: off
    timestamp: on
}

quorum {
    provider: corosync_votequorum
}

در این پیکربندی:

• bindnetaddr: آدرس شبکه‌ای که گره‌ها به آن متصل خواهند شد.
• mcastaddr: آدرس پخش چندگانه برای ارتباطات.
• quorum: تنظیمات مربوط به مکانیزم رای‌گیری برای تصمیم‌گیری در شرایط بحرانی.

3. پیکربندی کلاستر با استفاده از PCS

برای پیکربندی کلاستر، ابتدا باید PCS را فعال کرده و سپس از آن برای تنظیم و راه‌اندازی کلاستر استفاده کنید. ابتدا PCS را بر روی گره‌ها فعال کنید:

sudo systemctl enable pcsd
sudo systemctl start pcsd

سپس باید رمز عبور مشترک برای کلاستر تنظیم شود. از دستور زیر برای تعیین رمز عبور استفاده کنید:

sudo pcs cluster auth node1 node2 -u hacluster -p password

در این دستور:

• node1 و node2 نام گره‌ها است.
• hacluster نام کاربری پیش‌فرض برای ابزارهای کلاستر است.
• password رمز عبور مشترک برای دسترسی به گره‌ها است.

بعد از تأیید اعتبار، کلاستر را با دستور زیر راه‌اندازی کنید:

sudo pcs cluster setup --name mycluster node1 node2

4. راه‌اندازی کلاستر و بررسی وضعیت

پس از راه‌اندازی کلاستر، باید کلاستر را شروع کنید:

sudo pcs cluster start --all

برای بررسی وضعیت کلاستر و اطمینان از درست کار کردن آن، از دستور زیر استفاده کنید:

sudo pcs status

این دستور وضعیت کلی کلاستر، وضعیت گره‌ها، منابع و وضعیت Failover را نمایش می‌دهد.

5. پیکربندی منابع برای مدیریت

برای مدیریت منابع در کلاستر، می‌توانیم منابع مختلف مانند IP‌های مجازی یا سرویس‌ها را پیکربندی کنیم. به عنوان مثال، برای اضافه کردن یک آدرس IP مجازی به کلاستر، از دستور زیر استفاده می‌شود:

sudo pcs resource create VirtualIP IPaddr2 ip=192.168.1.100 cidr_netmask=24 op monitor interval=30s

در این دستور:

• VirtualIP نام منبع است.
• IPaddr2 نوع منبع است.
• ip=192.168.1.100 آدرس IP مجازی است.
• cidr_netmask=24 زیرشبکه مرتبط با IP است.
• op monitor interval=30s نظارت بر این منبع هر ۳۰ ثانیه یک‌بار انجام می‌شود.

این تنظیمات باعث می‌شود که Pacemaker به‌طور خودکار وضعیت این منابع را بررسی کرده و در صورت خرابی، آنها را به گره دیگر منتقل کند.

جمع‌بندی

در این بخش، مراحل نصب و راه‌اندازی یک کلاستر ساده با دو گره با استفاده از ابزارهای Pacemaker و Corosync را بررسی کردیم. از نصب بسته‌ها تا پیکربندی فایل‌های Corosync، فعال‌سازی PCS، پیکربندی منابع و راه‌اندازی کلاستر، تمامی مراحل به‌طور دقیق توضیح داده شد. این پیکربندی ابتدایی می‌تواند به عنوان پایه‌ای برای ساخت کلاسترهای High Availability (HA) در محیط‌های تولیدی استفاده شود.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”پیکربندی اولیه Corosync و Pacemaker برای ایجاد ارتباطات پایه” subtitle=”توضیحات کامل”]برای راه‌اندازی یک کلاستر ساده با استفاده از Corosync و Pacemaker و ایجاد ارتباطات پایه بین گره‌ها، باید مراحل زیر را به‌دقت دنبال کنید. این مراحل شامل پیکربندی فایل‌های مربوط به Corosync، راه‌اندازی و پیکربندی Pacemaker، و بررسی وضعیت اولیه گره‌ها است.

مراحل پیکربندی اولیه Corosync و Pacemaker:

1. نصب Corosync و Pacemaker
2. پیکربندی فایل Corosync
3. پیکربندی Pacemaker برای مدیریت منابع
4. راه‌اندازی کلاستر
5. بررسی وضعیت کلاستر

1. نصب Corosync و Pacemaker

برای نصب Corosync و Pacemaker در گره‌ها، ابتدا از دستورات زیر استفاده کنید. توجه داشته باشید که دستورها بسته به توزیع لینوکس ممکن است متفاوت باشد.

برای توزیع‌های Debian/Ubuntu:

sudo apt update
sudo apt install pacemaker corosync pcs

برای توزیع‌های CentOS/RHEL:

sudo yum install pacemaker corosync pcs

2. پیکربندی فایل Corosync

پس از نصب، باید فایل پیکربندی Corosync را که در مسیر /etc/corosync/corosync.conf قرار دارد، پیکربندی کنید.

در این فایل باید تنظیمات زیر را اضافه یا ویرایش کنید:

totem {
    version: 2
    cluster_name: mycluster
    transport: udpu
    interface {
        ringnumber: 0
        bindnetaddr: 192.168.1.0   # آدرس شبکه برای گره‌ها
        mcastaddr: 226.94.1.1      # آدرس پخش چندگانه
        mcastport: 5405
    }
}

logging {
    to_stderr: yes
    to_logfile: yes
    logfile: /var/log/corosync/corosync.log
    debug: off
    timestamp: on
}

quorum {
    provider: corosync_votequorum
}

در این پیکربندی:

• bindnetaddr: آدرس شبکه‌ای که گره‌ها به آن متصل خواهند شد.
• mcastaddr: آدرس پخش چندگانه برای ارتباطات گره‌ها.
• quorum: تعیین میزان اعتبار برای رای‌گیری در شرایط بحرانی.

3. پیکربندی Pacemaker برای مدیریت منابع

پس از پیکربندی Corosync، نوبت به راه‌اندازی Pacemaker می‌رسد. ابتدا باید PCS را بر روی گره‌ها فعال کنید. از دستورات زیر برای فعال‌سازی و شروع PCS استفاده کنید:

sudo systemctl enable pcsd
sudo systemctl start pcsd

سپس باید رمز عبور مشترک برای کلاستر تنظیم شود:

sudo pcs cluster auth node1 node2 -u hacluster -p password

در این دستور:

• node1 و node2 نام گره‌ها است.
• hacluster نام کاربری پیش‌فرض برای دسترسی به کلاستر است.
• password رمز عبور مشترک برای دسترسی به گره‌ها است.

4. راه‌اندازی کلاستر

پس از پیکربندی، کلاستر را با استفاده از PCS راه‌اندازی کنید:

sudo pcs cluster setup --name mycluster node1 node2

پس از راه‌اندازی، کلاستر را شروع کنید:

sudo pcs cluster start --all

5. بررسی وضعیت کلاستر

برای بررسی وضعیت کلاستر و اطمینان از درستی عملکرد آن، از دستور زیر استفاده کنید:

sudo pcs status

این دستور وضعیت کلی کلاستر، وضعیت گره‌ها، منابع و وضعیت Failover را نمایش می‌دهد.

جمع‌بندی

در این بخش، پیکربندی اولیه Corosync و Pacemaker برای ایجاد ارتباطات پایه بین گره‌ها توضیح داده شد. از نصب بسته‌ها تا پیکربندی فایل‌های Corosync، فعال‌سازی PCS، و راه‌اندازی کلاستر، تمامی مراحل به‌طور دقیق بررسی شد. این پیکربندی‌ها به شما امکان می‌دهند تا یک کلاستر HA پایه را راه‌اندازی کرده و ارتباطات بین گره‌ها را به‌درستی پیکربندی کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 7. چالش‌ها و نیازمندی‌ها در پیاده‌سازی کلاسترهای HA در لینوکس”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”بررسی مشکلات احتمالی و نیازهای سیستم‌عامل در ایجاد یک کلاستر HA” subtitle=”توضیحات کامل”]در هنگام راه‌اندازی و پیکربندی کلاسترهای HA (High Availability) برای سیستم‌های لینوکسی، ممکن است با چالش‌ها و مشکلات مختلفی روبرو شوید که نیازمند توجه خاص به جزئیات فنی و تنظیمات سیستم‌عامل است. در این بخش، به بررسی مشکلات احتمالی، نیازهای سیستم‌عامل و راه‌حل‌های رایج برای رفع این مشکلات خواهیم پرداخت.

1. نیازهای سخت‌افزاری و شبکه‌ای

قبل از پیکربندی کلاستر HA، باید اطمینان حاصل کنید که سخت‌افزار و شبکه‌ی شما برای راه‌اندازی کلاستر مناسب است. برخی از نیازهای اولیه شامل موارد زیر است:

• شبکه پایدار و با پهنای باند کافی: تمام گره‌های کلاستر باید به‌طور مستقیم از طریق یک شبکه با پهنای باند مناسب و تأخیر کم به هم متصل شوند. تأخیر زیاد یا شبکه ناپایدار می‌تواند باعث بروز مشکلات در ارتباطات Corosync و Pacemaker شود.
• سخت‌افزار مشابه یا مشابه‌ترین: برای اینکه گره‌ها به‌طور صحیح با یکدیگر کار کنند، باید سخت‌افزار مشابهی استفاده کنید. این شامل پردازنده، حافظه، و فضای ذخیره‌سازی است. تفاوت‌های سخت‌افزاری می‌توانند باعث مشکلاتی در عملکرد کلاستر و هماهنگی میان گره‌ها شوند.
• آدرس‌دهی IP و ارتباطات شبکه: باید از آدرس‌های IP ثابت برای هر گره استفاده کنید و همچنین تنظیمات درست برای پیکربندی Multicast یا Unicast (بسته به شبکه) انجام شود.

2. تنظیمات فایروال و امنیت

یکی از مهم‌ترین مسائل در راه‌اندازی کلاسترهای HA، تنظیمات فایروال و سیاست‌های امنیتی است که باید به‌درستی پیکربندی شوند تا ارتباطات بین گره‌ها قطع نشوند:

• پورت‌ها و پروتکل‌های لازم: برای ارتباطات میان گره‌ها، باید پورت‌ها و پروتکل‌های خاصی در فایروال باز باشند. به‌طور معمول، برای Corosync و Pacemaker پورت‌های زیر مورد نیاز هستند:
  • Corosync: پورت‌های 5404 و 5405 برای ارتباطات بین گره‌ها.
  • PCS: پورت 2224 برای ارتباطات PCS بین گره‌ها.

  برای باز کردن این پورت‌ها در فایروال از دستورات زیر استفاده کنید:

  sudo ufw allow 5404:5405/udp
  sudo ufw allow 2224/tcp
  

  برای توزیع‌های RHEL/CentOS از دستور زیر استفاده کنید:

  sudo firewall-cmd --zone=public --add-port=5404-5405/udp --permanent
  sudo firewall-cmd --zone=public --add-port=2224/tcp --permanent
  sudo firewall-cmd --reload
  

• SELinux و AppArmor: سیستم‌های امنیتی مانند SELinux یا AppArmor می‌توانند مانع ارتباطات گره‌ها شوند. در صورتی که SELinux فعال باشد، باید آن را به‌طور موقت غیرفعال کنید یا برای اجتناب از مشکلات، قوانین خاصی برای Corosync و Pacemaker ایجاد کنید.برای غیرفعال کردن SELinux موقتی می‌توانید از دستور زیر استفاده کنید:

  sudo setenforce 0
  

3. همگام‌سازی زمان

در یک کلاستر HA، همگام‌سازی دقیق زمان میان گره‌ها اهمیت زیادی دارد. اگر زمان سیستم‌ها با هم هماهنگ نباشد، ممکن است کلاستر دچار مشکلاتی در شناسایی و مدیریت منابع شود. استفاده از NTP (Network Time Protocol) برای همگام‌سازی زمان، از ضروریات است.

برای نصب و پیکربندی NTP، از دستورات زیر استفاده کنید:

• برای توزیع‌های Debian/Ubuntu:

  sudo apt update
  sudo apt install ntp
  sudo systemctl enable ntp
  sudo systemctl start ntp
  

• برای توزیع‌های RHEL/CentOS:

  sudo yum install ntp
  sudo systemctl enable ntpd
  sudo systemctl start ntpd
  

4. منابع مشترک و دسترسی به داده‌ها

برای پیکربندی صحیح کلاسترهای HA، باید مطمئن شوید که گره‌ها به منابع مشترک (مانند دیسک‌ها و ذخیره‌سازی شبکه‌ای) دسترسی دارند. در اینجا دو نکته مهم وجود دارد:

• دسترسی به دیسک‌های مشترک: گره‌ها باید بتوانند به دیسک‌های مشترک که برای ذخیره‌سازی داده‌ها استفاده می‌شوند دسترسی پیدا کنند. در این زمینه، باید از سیستم‌های شبکه‌ای ذخیره‌سازی (NAS) یا دیسک‌های مشترک FC (Fibre Channel) استفاده کنید.
• شبکه ذخیره‌سازی iSCSI: یکی از راهکارهای محبوب برای به اشتراک‌گذاری دیسک‌ها در کلاسترهای HA، استفاده از iSCSI است. برای نصب و پیکربندی iSCSI در لینوکس، از دستورات زیر استفاده کنید:

  sudo apt install open-iscsi
  sudo systemctl enable iscsid
  sudo systemctl start iscsid
  

5. پیکربندی مناسب برای Failover و Failback

یکی از چالش‌های اصلی در کلاسترهای HA، مدیریت Failover (انتقال منابع در صورت خرابی) و Failback (بازگشت به گره اصلی بعد از رفع مشکل) است. اگر Failover به‌درستی پیکربندی نشود، در صورت خرابی گره، منابع ممکن است به‌درستی به گره دیگر منتقل نشوند.

برای پیکربندی Failover در Pacemaker، از دستورات زیر استفاده کنید:

sudo pcs resource create my_service ocf:heartbeat:Dummy op monitor interval=30s

در این دستور:

• my_service نام منابعی است که می‌خواهید Failover را روی آن اعمال کنید.
• interval=30s مدت زمانی است که سیستم باید وضعیت منبع را بررسی کند.

6. مشکلات مربوط به Quorum و Split-Brain

یکی دیگر از مشکلات رایج در کلاسترهای HA، مربوط به Quorum (حداقل تعداد گره‌ها برای تصمیم‌گیری) و Split-Brain است. زمانی که ارتباطات بین گره‌ها قطع می‌شود، ممکن است وضعیت Split-Brain پیش آید که باعث می‌شود چند گره به‌طور مستقل منابع را مدیریت کنند.

برای جلوگیری از این مشکل، باید Quorum را به‌درستی پیکربندی کنید تا تصمیمات در شرایط بحرانی گرفته شود. این کار با تنظیم گزینه‌های quorum در فایل Corosync و استفاده از ابزار Pacemaker انجام می‌شود.

جمع‌بندی

در این بخش، به بررسی مشکلات احتمالی و نیازهای سیستم‌عامل برای ایجاد یک کلاستر HA پرداخته شد. توجه به مواردی مانند تنظیمات شبکه، فایروال، همگام‌سازی زمان، منابع مشترک، و پیکربندی صحیح Failover و Quorum از اهمیت زیادی برخوردار است. با پیکربندی دقیق این جزئیات و توجه به مسائل امنیتی، می‌توان مشکلات رایج را رفع کرد و کلاستری با قابلیت اطمینان بالا راه‌اندازی کرد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”الزامات سخت‌افزاری و نرم‌افزاری برای راه‌اندازی موفق یک کلاستر” subtitle=”توضیحات کامل”]برای راه‌اندازی یک کلاستر با قابلیت High Availability (HA)، نیاز است که سخت‌افزار و نرم‌افزارها به‌طور دقیق و متناسب با نیازهای کلاستر پیکربندی شوند. این الزامات به‌شکلی طراحی‌شده‌اند که عملکرد پایدار و بدون وقفه‌ای برای سرویس‌ها و منابع در دسترس فراهم کنند. در این بخش به بررسی الزامات سخت‌افزاری و نرم‌افزاری برای راه‌اندازی یک کلاستر موفق خواهیم پرداخت.

1. الزامات سخت‌افزاری

الزامات سخت‌افزاری کلاستر به‌طور مستقیم با قابلیت اطمینان و عملکرد سیستم ارتباط دارد. هر گونه مشکل سخت‌افزاری می‌تواند باعث ایجاد خطاهای موقت یا دائمی در کلاستر شود. بنابراین باید به‌دقت انتخاب شوند.

1.1. گره‌های کلاستر

• تعداد گره‌ها: معمولاً کلاسترهای HA از حداقل دو گره (Node) تشکیل می‌شوند. با این حال، می‌توانند شامل تعداد بیشتری گره برای تحمل بار بیشتر یا فراهم کردن قابلیت دسترس‌پذیری بالاتر باشند.
• سخت‌افزار مشابه: برای اطمینان از عملکرد یکسان گره‌ها، سخت‌افزارهای مشابه باید در تمامی گره‌ها استفاده شوند. این شامل پردازنده‌ها، حافظه و دیسک‌ها می‌شود. تفاوت‌های سخت‌افزاری می‌تواند باعث مشکلات در همگام‌سازی و مدیریت منابع شود.

1.2. فضای ذخیره‌سازی مشترک

کلاسترهای HA نیاز به دسترسی به فضای ذخیره‌سازی مشترک دارند تا منابع به‌طور یکسان میان گره‌ها قابل دسترس باشند.

• شبکه ذخیره‌سازی: فضای ذخیره‌سازی مشترک معمولاً از طریق NFS (Network File System)، SAN (Storage Area Network) یا iSCSI فراهم می‌شود.
• درایوهای مشترک: اگر از Fibre Channel یا SCSI استفاده می‌شود، باید دیسک‌ها به‌طور مشترک در تمامی گره‌ها قابل دسترس باشند.

1.3. شبکه

ارتباطات شبکه‌ای میان گره‌ها در کلاسترهای HA اهمیت زیادی دارد.

• شبکه خصوصی: گره‌ها باید به یکدیگر از طریق شبکه‌های خصوصی با پهنای باند بالا و تأخیر کم متصل شوند.
• پهنای باند کافی: برای جلوگیری از ترافیک اضافی و تأخیر در پردازش داده‌ها، پهنای باند کافی برای ارسال داده‌ها بین گره‌ها ضروری است.
• آدرس‌دهی IP ثابت: برای جلوگیری از تغییرات در اتصال گره‌ها، باید از آدرس‌های IP ثابت استفاده شود. معمولاً گره‌ها از Static IP یا DHCP با MAC binding استفاده می‌کنند.

2. الزامات نرم‌افزاری

الزامات نرم‌افزاری برای راه‌اندازی کلاسترهای HA شامل سیستم‌عامل، نرم‌افزارهای کلاسترینگ و ابزارهای مدیریت است که برای پیکربندی، مانیتورینگ و مدیریت گره‌ها استفاده می‌شوند.

2.1. سیستم‌عامل

• سیستم‌عامل لینوکس: اغلب کلاسترهای HA بر روی سیستم‌عامل‌های لینوکسی نظیر Red Hat Enterprise Linux (RHEL)، CentOS و Ubuntu راه‌اندازی می‌شوند. برای این کار باید از نسخه‌های مناسب سیستم‌عامل که قابلیت پشتیبانی از کلاسترهای HA را دارند استفاده کنید.
• پشتیبانی از کلاسترینگ: سیستم‌عامل باید از ویژگی‌هایی مانند Corosync و Pacemaker پشتیبانی کند. این ابزارها برای ایجاد ارتباطات شبکه‌ای بین گره‌ها و مدیریت منابع کلاستر به‌کار می‌روند.

2.2. نرم‌افزار کلاسترینگ

برای مدیریت منابع و ارتباطات میان گره‌ها در کلاسترهای HA، نرم‌افزارهای مختلفی وجود دارند که باید به‌درستی نصب و پیکربندی شوند.

• Pacemaker: این ابزار یکی از مهم‌ترین اجزای مدیریت منابع کلاستر است که به مدیریت منابع و خدمات در گره‌های مختلف کمک می‌کند. Pacemaker مسئول انتقال منابع از یک گره به گره دیگر در صورت خرابی است.برای نصب Pacemaker در توزیع‌های RHEL/CentOS می‌توان از دستور زیر استفاده کرد:

  sudo yum install pacemaker
  

  در توزیع‌های Ubuntu/Debian:

  sudo apt-get install pacemaker
  

• Corosync: این نرم‌افزار برای ایجاد ارتباطات امن بین گره‌ها در کلاستر استفاده می‌شود. Corosync از پروتکل‌های Multicast یا Unicast برای برقراری ارتباط میان گره‌ها استفاده می‌کند.نصب Corosync در RHEL/CentOS:

  sudo yum install corosync
  

  در Ubuntu/Debian:

  sudo apt-get install corosync
  

2.3. ابزار مدیریت کلاستر

• pcs: این ابزار برای پیکربندی و مدیریت کلاسترهای HA در سیستم‌های لینوکسی استفاده می‌شود. شما می‌توانید از pcs برای اضافه کردن منابع، مدیریت گره‌ها و تنظیمات سایر اجزای کلاستر استفاده کنید.برای نصب pcs در RHEL/CentOS:

  sudo yum install pcs
  

  در Ubuntu/Debian:

  sudo apt-get install pcs
  

2.4. ابزارهای پایش و نظارت

برای اطمینان از عملکرد صحیح کلاستر، باید از ابزارهای نظارت استفاده کنید.

• ClusterMon: این ابزار برای نظارت بر وضعیت کلاسترهای HA و نمایش وضعیت گره‌ها و منابع کلاستر استفاده می‌شود.
• Nagios یا Zabbix: برای مانیتورینگ منابع و پیگیری وضعیت گره‌ها و سرویس‌ها می‌توان از این ابزارها استفاده کرد.

3. نیازهای امنیتی

در یک کلاستر HA، مسائل امنیتی از اهمیت ویژه‌ای برخوردارند. تنظیمات فایروال، SELinux، و AppArmor باید به‌طور دقیق پیکربندی شوند تا از دسترسی غیرمجاز و حملات جلوگیری شود.

• SELinux: باید تنظیمات مربوط به SELinux را در صورت نیاز به‌درستی پیکربندی کنید تا از محدودیت‌های امنیتی جلوگیری نشود.برای غیرفعال کردن SELinux موقتاً:

  sudo setenforce 0
  

• فایروال: باید پورت‌های موردنیاز برای Pacemaker و Corosync در فایروال باز باشند.برای باز کردن پورت‌ها در CentOS/RHEL:

  sudo firewall-cmd --zone=public --add-port=5404-5405/udp --permanent
  sudo firewall-cmd --zone=public --add-port=2224/tcp --permanent
  sudo firewall-cmd --reload
  

جمع‌بندی

برای راه‌اندازی یک کلاستر HA موفق، نیاز است که هر دو بخش سخت‌افزاری و نرم‌افزاری به‌طور دقیق و هماهنگ با یکدیگر پیکربندی شوند. الزامات سخت‌افزاری شامل گره‌های مشابه، شبکه‌ی پایدار و فضای ذخیره‌سازی مشترک است. در بخش نرم‌افزاری، نصب و پیکربندی ابزارهایی مانند Corosync، Pacemaker و pcs برای مدیریت منابع و ارتباطات گره‌ها ضروری است. همچنین، توجه به مسائل امنیتی و تنظیمات فایروال از دیگر نکات حائز اهمیت برای راه‌اندازی یک کلاستر پایدار و ایمن می‌باشد.[/cdb_course_lesson][cdb_course_lesson title=”فصل 8. آشنایی با سیستم‌عامل‌های لینوکس مناسب برای HA”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”بررسی توزیع‌های لینوکس مانند CentOS، RHEL و Ubuntu که برای ایجاد کلاسترهای HA استفاده می‌شوند” subtitle=”توضیحات کامل”]برای راه‌اندازی کلاسترهای High Availability (HA) در لینوکس، استفاده از توزیع‌های مناسب با قابلیت پشتیبانی از ابزارهای کلاسترینگ و ویژگی‌های HA بسیار اهمیت دارد. در این بخش به بررسی سه توزیع محبوب لینوکس برای ایجاد کلاسترهای HA خواهیم پرداخت: CentOS، RHEL (Red Hat Enterprise Linux) و Ubuntu. هر یک از این توزیع‌ها ویژگی‌های خاص خود را دارند که باید به آن‌ها توجه شود تا انتخاب درستی برای راه‌اندازی کلاستر انجام شود.

1. CentOS

CentOS یک توزیع لینوکس رایگان و متن‌باز است که بر اساس کدهای منبع Red Hat Enterprise Linux (RHEL) ساخته شده است. این توزیع به‌طور گسترده در محیط‌های سروری برای ایجاد کلاسترهای HA استفاده می‌شود. از آنجا که CentOS از RHEL منشأ می‌گیرد، امکانات و قابلیت‌هایی مشابه با RHEL را در اختیار کاربران قرار می‌دهد.

ویژگی‌ها:

• سازگاری با RHEL: CentOS از بسته‌های نرم‌افزاری و کدهای منبع RHEL استفاده می‌کند، بنابراین از لحاظ قابلیت‌ها و ابزارهای مدیریتی مشابه با RHEL است.
• رایگان و متن‌باز: CentOS به‌طور رایگان در دسترس است و بنابراین برای استفاده در پروژه‌های مختلف اقتصادی و تجاری مناسب است.
• پشتیبانی از ابزارهای کلاسترینگ: CentOS به‌طور کامل از ابزارهایی مانند Pacemaker و Corosync پشتیبانی می‌کند که برای مدیریت کلاسترهای HA ضروری هستند.

نصب ابزارهای کلاسترینگ در CentOS:

برای نصب Corosync و Pacemaker در CentOS از دستورات زیر استفاده می‌کنیم:

sudo yum install pacemaker corosync pcs

2. RHEL (Red Hat Enterprise Linux)

RHEL یک توزیع لینوکس تجاری است که توسط شرکت Red Hat برای محیط‌های سروری و تجاری توسعه داده شده است. این توزیع از نظر پایداری، امنیت و پشتیبانی تجاری برای ایجاد کلاسترهای HA مناسب است.

ویژگی‌ها:

• پشتیبانی تجاری: از آنجا که RHEL یک توزیع تجاری است، پشتیبانی رسمی و به‌روزرسانی‌های امنیتی از طریق Red Hat فراهم می‌شود.
• پایداری و قابلیت اطمینان: RHEL برای محیط‌های کاری که نیاز به پایداری بالا دارند، طراحی شده است.
• ابزارهای کلاسترینگ پیشرفته: RHEL ابزارهای قدرتمندی مانند Pacemaker، Corosync و cman را برای ایجاد کلاسترهای HA فراهم می‌کند.
• گواهینامه‌ها و استانداردها: RHEL به دلیل داشتن گواهینامه‌های مختلف در صنایع مختلف، انتخاب محبوبی برای شرکت‌ها و سازمان‌های بزرگ است.

نصب ابزارهای کلاسترینگ در RHEL:

برای نصب ابزارهای کلاسترینگ در RHEL از دستورات زیر استفاده می‌شود:

sudo yum install pacemaker corosync pcs

3. Ubuntu

Ubuntu یکی از محبوب‌ترین توزیع‌های لینوکس برای استفاده در سرورها و محیط‌های توسعه است. این توزیع به‌ویژه برای کاربران تازه‌کار و کسانی که به دنبال یک سیستم‌عامل ساده و راحت برای نصب و استفاده هستند، مناسب است. در بخش کلاسترهای HA، Ubuntu با ابزارهای مختلفی از جمله Pacemaker و Corosync سازگار است.

ویژگی‌ها:

• رایگان و متن‌باز: Ubuntu مانند CentOS یک توزیع رایگان و متن‌باز است که در دسترس عموم قرار دارد.
• سهولت استفاده و نصب: این توزیع به‌طور خاص برای کاربرانی که به دنبال یک سیستم‌عامل ساده هستند طراحی شده است. نصب و پیکربندی ابزارهای کلاسترینگ در Ubuntu بسیار ساده است.
• پشتیبانی از ابزارهای کلاسترینگ: Ubuntu از ابزارهایی مانند Pacemaker، Corosync و pcs پشتیبانی می‌کند که برای راه‌اندازی کلاسترهای HA موردنیاز هستند.
• پشتیبانی از نسخه‌های LTS: نسخه‌های Long-Term Support (LTS) از Ubuntu از پشتیبانی طولانی‌مدت برخوردارند که آن را برای محیط‌های کاری حساس به امنیت مناسب می‌کند.

نصب ابزارهای کلاسترینگ در Ubuntu:

برای نصب Pacemaker و Corosync در Ubuntu از دستور زیر استفاده می‌کنیم:

sudo apt-get install pacemaker corosync pcs

4. مقایسه توزیع‌ها برای راه‌اندازی کلاسترهای HA

در اینجا مقایسه‌ای میان CentOS، RHEL و Ubuntu انجام داده‌ایم تا کمک کند انتخاب بهتری برای راه‌اندازی کلاستر انجام شود:

ویژگی	CentOS	RHEL	Ubuntu
رایگان یا تجاری	رایگان	تجاری	رایگان
پشتیبانی تجاری	ندارد	پشتیبانی رسمی از Red Hat	ندارد
پایداری و امنیت	بالا، مشابه RHEL	بسیار بالا و تست‌شده	بالا، به‌ویژه در نسخه‌های LTS
سهولت نصب	نصب نسبتاً ساده	نصب و پیکربندی پیچیده‌تر	نصب ساده و سریع
ابزارهای کلاسترینگ	کامل (Pacemaker، Corosync)	کامل (Pacemaker، Corosync)	کامل (Pacemaker، Corosync)
مناسب برای شرکت‌ها	مناسب برای پروژه‌های کوچک و متوسط	مناسب برای پروژه‌های بزرگ و سازمان‌ها	مناسب برای محیط‌های کوچک و متوسط

جمع‌بندی

برای راه‌اندازی کلاسترهای HA، انتخاب توزیع لینوکس بستگی به نیازهای سازمانی و پروژه دارد. اگر به دنبال یک توزیع رایگان و پشتیبانی مشابه RHEL هستید، CentOS گزینه مناسبی است. در صورتی که به پشتیبانی تجاری نیاز دارید و اولویت شما پایداری بالاست، RHEL بهترین انتخاب است. همچنین، اگر به دنبال یک سیستم‌عامل ساده و راحت با نصب آسان هستید، Ubuntu به‌ویژه نسخه‌های LTS می‌تواند گزینه مناسبی برای پروژه‌های کوچک و متوسط باشد.[/cdb_course_lesson][cdb_course_lesson title=”فصل 9. تفاوت کلاسترهای HA با سایر روش‌های دسترس‌پذیری”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مقایسه کلاسترها با روش‌های دیگری مانند Load Balancing یا Fault Tolerance” subtitle=”توضیحات کامل”]در دنیای فناوری اطلاعات، برای اطمینان از دسترس‌پذیری بالا، مقیاس‌پذیری و تحمل خطا، استفاده از روش‌های مختلفی نظیر کلاسترینگ (Clustering)، Load Balancing (تعادل بار) و Fault Tolerance (تحمل خطا) مطرح می‌شود. این سه روش به‌طور ویژه برای ارتقاء کارایی و پایداری سیستم‌ها طراحی شده‌اند، اما هر کدام ویژگی‌ها و کاربردهای خاص خود را دارند. در این بخش، به بررسی و مقایسه این روش‌ها خواهیم پرداخت تا تفاوت‌ها و نقاط قوت و ضعف هر کدام مشخص شود.

1. کلاسترینگ (Clustering)

کلاسترینگ به فرآیند اتصال چندین گره (Node) در یک شبکه برای ایجاد یک واحد یکپارچه و مقاوم در برابر خطا گفته می‌شود. در کلاسترینگ، هر گره (سرور) به طور مستقل عمل می‌کند، اما منابع و وظایف به‌طور هماهنگ بین گره‌ها توزیع می‌شود.

ویژگی‌ها:

• دسترس‌پذیری بالا (High Availability): در کلاسترینگ، اگر یک گره دچار مشکل شود، دیگر گره‌ها می‌توانند وظایف آن را انجام دهند و سیستم از دسترس خارج نمی‌شود.
• مقیاس‌پذیری (Scalability): در کلاسترینگ می‌توان به راحتی گره‌های جدید اضافه کرد تا ظرفیت سیستم افزایش یابد.
• توزیع بار (Load Distribution): بار کاری می‌تواند بین گره‌ها توزیع شود و از وقوع ترافیک سنگین بر روی یک گره جلوگیری کند.

معایب:

• پیچیدگی پیکربندی و مدیریت: راه‌اندازی و مدیریت کلاسترها پیچیده است و نیاز به ابزارهایی مثل Pacemaker و Corosync برای هماهنگی گره‌ها دارد.
• هزینه بالا: به دلیل نیاز به سخت‌افزار اضافی و پیچیدگی‌های نرم‌افزاری، راه‌اندازی کلاسترها می‌تواند هزینه‌بر باشد.

2. Load Balancing (تعادل بار)

Load Balancing یا تعادل بار فرآیندی است که به توزیع درخواست‌ها و ترافیک بین چندین سرور یا منابع مختلف برای بهینه‌سازی استفاده از منابع و جلوگیری از بارگذاری بیش از حد یک سیستم خاص گفته می‌شود.

ویژگی‌ها:

• توزیع بار بهینه: با توزیع ترافیک و درخواست‌ها بین چندین سرور، این روش از ایجاد مشکلات عملکردی مانند بارگذاری بیش از حد جلوگیری می‌کند.
• دسترس‌پذیری و مقیاس‌پذیری: در صورت از کار افتادن یک سرور، درخواست‌ها به سرورهای دیگر هدایت می‌شوند و می‌توان سرورهای بیشتری را به‌راحتی اضافه کرد.
• ساده‌تر از کلاسترینگ: پیاده‌سازی و مدیریت Load Balancer ها نسبت به کلاسترینگ ساده‌تر است.

معایب:

• نیاز به سخت‌افزار یا نرم‌افزار اضافی: استفاده از Load Balancer برای توزیع بار نیاز به سخت‌افزار یا نرم‌افزار خاصی دارد.
• عدم تحمل خطای کامل: در صورتی که یک سرور از کار بیفتد، امکان وجود مشکل برای یکبار در صورت عدم پیکربندی صحیح وجود دارد.

3. Fault Tolerance (تحمل خطا)

Fault Tolerance به توانایی یک سیستم در ادامه کار بدون وقفه در صورت بروز خطا یا مشکل در یکی از اجزای سیستم گفته می‌شود. در این روش، سیستم به گونه‌ای طراحی می‌شود که حتی در صورت وقوع خرابی در اجزای مختلف، بتواند به عملکرد خود ادامه دهد.

ویژگی‌ها:

• پایداری و تداوم سرویس: سیستم‌های مقاوم در برابر خطا می‌توانند در صورت بروز مشکلات سخت‌افزاری یا نرم‌افزاری، به کار خود ادامه دهند.
• سرعت واکنش به خطاها: معمولا خطاها به سرعت شناسایی شده و اقداماتی برای بازگرداندن سیستم به حالت پایدار انجام می‌شود.
• عدم نیاز به تغییرات عمده: برخلاف کلاسترینگ، سیستم‌های با تحمل خطا می‌توانند به طور خودکار خرابی‌ها را مدیریت کنند و نیازی به تغییرات پیچیده در سیستم ندارند.

معایب:

• هزینه‌های بالا: طراحی سیستم‌های مقاوم در برابر خطا نیاز به سرمایه‌گذاری زیادی دارد.
• پیچیدگی بالا: طراحی و پیاده‌سازی چنین سیستم‌هایی ممکن است به دانش و تجربه بالایی نیاز داشته باشد.

مقایسه روش‌ها

ویژگی	کلاسترینگ (Clustering)	Load Balancing	Fault Tolerance
دسترس‌پذیری بالا	بسیار بالا (اگر یک گره از کار بیفتد، دیگر گره‌ها فعال می‌شوند)	بالا (در صورت خرابی یک سرور، درخواست‌ها به سرورهای دیگر هدایت می‌شوند)	بسیار بالا (سیستم همچنان ادامه کار می‌دهد)
مقیاس‌پذیری	بسیار بالا (می‌توان به راحتی گره‌های جدید اضافه کرد)	بالا (می‌توان سرورهای بیشتری اضافه کرد)	محدود به نوع طراحی سیستم
پیچیدگی مدیریت	پیچیده (نیاز به ابزارهای مدیریتی و هماهنگی گره‌ها دارد)	ساده‌تر (نیاز به مدیریت کمتر)	پیچیده (نیاز به طراحی سیستم مقاوم در برابر خطا)
هزینه	نسبتاً بالا (نیاز به سخت‌افزار اضافی و پیکربندی پیچیده)	متوسط (نیاز به سخت‌افزار یا نرم‌افزار اضافی)	بسیار بالا (نیاز به سخت‌افزار خاص و طراحی پیچیده)
کاربردهای معمول	برای اطمینان از دسترس‌پذیری و مقیاس‌پذیری در سرویس‌های حیاتی	برای توزیع ترافیک و بهینه‌سازی استفاده از منابع	برای سیستم‌های حیاتی که نیاز به پایداری کامل دارند

جمع‌بندی

در نهایت، انتخاب میان کلاسترینگ، Load Balancing و Fault Tolerance بستگی به نیازهای خاص پروژه و سازمان دارد. اگر هدف اصلی دسترس‌پذیری بالا و مقیاس‌پذیری است، کلاسترینگ می‌تواند گزینه مناسب‌تری باشد. در صورتی که نیاز به توزیع بهینه بار بین چندین سرور دارید و هزینه‌ها نیز مدنظر هستند، استفاده از Load Balancing مناسب خواهد بود. برای پایداری کامل و ادامه کار در صورت خرابی، Fault Tolerance بهترین انتخاب است، هرچند که نیاز به هزینه‌ها و پیچیدگی‌های بالاتری دارد.[/cdb_course_lesson][cdb_course_lesson title=”فصل 10. آشنایی با قوانین و الزامات نظارتی در پیاده‌سازی کلاسترهای HA”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”بررسی استانداردها و بهترین شیوه‌های صنعتی در پیاده‌سازی سیستم‌های HA در محیط‌های تجاری” subtitle=”توضیحات کامل”]در دنیای فناوری اطلاعات، سیستم‌های دسترس‌پذیری بالا (High Availability – HA) از اهمیت ویژه‌ای برخوردار هستند. این سیستم‌ها می‌بایست قادر به ارائه سرویس‌های پایدار و بدون وقفه باشند تا کسب‌وکارها بتوانند بدون قطعی و با حداقل زمان خرابی عمل کنند. پیاده‌سازی موفق این سیستم‌ها نیازمند رعایت استانداردها و بهترین شیوه‌های صنعتی است تا بتوان از مزایای آن به طور بهینه استفاده کرد.

در این بخش، به بررسی استانداردها و شیوه‌های بهترین در پیاده‌سازی سیستم‌های HA در محیط‌های تجاری می‌پردازیم.

1. تحلیل نیازمندی‌ها و طراحی معماری

یکی از اولین قدم‌های پیاده‌سازی سیستم‌های HA، انجام تحلیل دقیق نیازمندی‌ها و طراحی معماری صحیح است. در این مرحله باید با توجه به نیازهای تجاری و نوع سرویس‌هایی که قرار است ارائه شود، معماری مناسب انتخاب شود.

بهترین شیوه‌ها:

• تحلیل دقیق نیازمندی‌ها: قبل از شروع به پیاده‌سازی، باید تمام نیازمندی‌های تجاری، ظرفیت ترافیک، و سطح دسترس‌پذیری مورد نیاز مشخص شوند.
• انتخاب مناسب معماری: معماری Active/Passive یا Active/Active بسته به نیازمندی‌ها انتخاب می‌شود. برای سرویس‌هایی که نیاز به مقیاس‌پذیری بالا دارند، معماری Active/Active پیشنهاد می‌شود.
• استفاده از ابزارهای مدیریت کلاستر: ابزارهایی مانند Pacemaker و Corosync برای هماهنگی گره‌ها و مدیریت منابع کلاستر باید در این مرحله انتخاب شوند.

2. انتخاب مناسب سخت‌افزار و نرم‌افزار

برای پیاده‌سازی سیستم‌های HA، انتخاب صحیح سخت‌افزار و نرم‌افزار از اهمیت بالایی برخوردار است. این انتخاب باید طوری انجام شود که سیستم بتواند در برابر خطاها و خرابی‌ها تاب‌آوری داشته باشد.

بهترین شیوه‌ها:

• سخت‌افزار مقاوم: برای گره‌ها باید از سخت‌افزارهای قدرتمند و مقاوم در برابر خطا استفاده شود. در این راستا، استفاده از سرورهای با قابلیت RAID برای مدیریت ذخیره‌سازی و همچنین استفاده از شبکه‌های متعدد برای اطمینان از ارتباط پایدار توصیه می‌شود.
• استفاده از نرم‌افزارهای پایدار و مقیاس‌پذیر: سیستم‌عامل‌هایی نظیر RHEL، CentOS و Ubuntu برای پیاده‌سازی کلاسترهای HA گزینه‌های مناسبی هستند.

3. پیکربندی صحیح شبکه

شبکه یکی از ارکان اصلی سیستم‌های HA است. اطمینان از کارکرد صحیح شبکه و داشتن شبکه‌هایی با باند پهنای مناسب و اتصال پایدار بین گره‌ها از نکات حیاتی در پیاده‌سازی HA است.

بهترین شیوه‌ها:

• استفاده از شبکه‌های مجزا: توصیه می‌شود که شبکه‌های ارتباطی میان گره‌ها و شبکه‌های ارتباطی کاربران از هم جدا باشند. این کار به جلوگیری از تداخل بار و افزایش امنیت کمک می‌کند.
• پیکربندی شبکه برای failover سریع: باید از مکانیزم‌های Failover سریع برای انتقال ترافیک به گره‌های دیگر در صورت خرابی یک گره استفاده شود.

4. مدیریت منابع و خودکارسازی

مدیریت منابع در سیستم‌های HA باید به صورت خودکار انجام شود. این کار به حفظ تعادل بار و جلوگیری از خرابی‌های ناشی از بار زیاد کمک می‌کند. همچنین، خودکارسازی فرآیندهای مختلف مانند backup گیری، Failover و Monitor کردن سیستم‌ها، موجب افزایش کارایی و کاهش احتمال خطا می‌شود.

بهترین شیوه‌ها:

• استفاده از Pacemaker برای مدیریت منابع: Pacemaker یک ابزار محبوب در مدیریت منابع در سیستم‌های کلاستر است. این ابزار می‌تواند به‌طور خودکار گره‌های فعال را مانیتور کرده و در صورت خرابی آن‌ها، منابع را به گره‌های سالم منتقل کند.
• استفاده از ابزارهای خودکارسازی: ابزارهایی نظیر Ansible و Puppet برای پیکربندی و نگهداری خودکار کلاسترها به‌ویژه در محیط‌های بزرگ توصیه می‌شود.

5. آزمایش و ارزیابی سیستم‌های HA

قبل از استفاده از سیستم‌های HA در محیط‌های تولید، آزمایش و ارزیابی صحیح این سیستم‌ها ضروری است. این ارزیابی‌ها باید شامل آزمون‌های فشاری و شبیه‌سازی خرابی‌ها باشد.

بهترین شیوه‌ها:

• شبیه‌سازی خرابی‌ها (Failure Simulation): برای اطمینان از عملکرد صحیح سیستم در صورت بروز خطا، باید شبیه‌سازی خرابی در سیستم انجام شود. این آزمایش باید شامل از کار افتادن یک گره یا خرابی شبکه باشد.
• آزمایش زیر بار (Load Testing): برای اطمینان از مقیاس‌پذیری، باید سیستم زیر بار سنگین آزمایش شود تا میزان تحمل و پاسخ‌دهی آن ارزیابی شود.

6. نظارت و نگهداری

برای اطمینان از عملکرد صحیح و پایدار سیستم‌های HA، نظارت مستمر و نگهداری سیستم از الزامات است. این کار باعث می‌شود تا مشکلات احتمالی به سرعت شناسایی شده و به موقع برطرف شوند.

بهترین شیوه‌ها:

• استفاده از ابزارهای مانیتورینگ: ابزارهایی نظیر Nagios، Zabbix و Prometheus برای نظارت بر عملکرد گره‌ها و منابع سیستم باید مورد استفاده قرار گیرند.
• نگهداری و بروزرسانی مستمر: برای جلوگیری از مشکلات امنیتی و عملکردی، باید سیستم‌ها و نرم‌افزارهای مرتبط به‌طور منظم بروزرسانی شوند.

7. پشتیبان‌گیری و بازیابی

پشتیبان‌گیری و داشتن برنامه بازیابی مناسب از دیگر الزامات پیاده‌سازی سیستم‌های HA است. این روش‌ها اطمینان می‌دهند که در صورت وقوع خرابی جدی، داده‌ها و تنظیمات از دست نخواهند رفت و سرویس‌ها مجدداً در کمترین زمان ممکن باز می‌گردند.

بهترین شیوه‌ها:

• پشتیبان‌گیری منظم: باید پشتیبان‌گیری‌های منظم از داده‌ها، تنظیمات و پیکربندی‌ها انجام شود.
• برنامه بازیابی از خطا (Disaster Recovery): برنامه‌ای برای بازیابی سریع و مؤثر از خرابی‌ها باید طراحی و آزمایش شود تا در صورت نیاز، عملیات بازیابی به سرعت انجام گیرد.

جمع‌بندی

در پیاده‌سازی سیستم‌های HA در محیط‌های تجاری، رعایت استانداردها و بهترین شیوه‌های صنعتی از اهمیت بالایی برخوردار است. از تحلیل نیازمندی‌ها و طراحی معماری گرفته تا انتخاب سخت‌افزار و نرم‌افزار مناسب، هر مرحله باید به دقت انجام شود. همچنین، نظارت مستمر، پشتیبان‌گیری و شبیه‌سازی خرابی‌ها از الزامات کلیدی در پیاده‌سازی موفق این سیستم‌ها هستند. با رعایت این شیوه‌ها، می‌توان به یک سیستم HA پایدار، مقیاس‌پذیر و مقاوم در برابر خطا دست یافت که باعث حفظ و ارتقاء دسترس‌پذیری خدمات در محیط‌های تجاری خواهد شد.[/cdb_course_lesson][/cdb_course_lessons]

[cdb_course_lessons title=”بخش 3. پیکربندی Pacemaker و Corosync”][cdb_course_lesson title=”فصل 1. نصب و پیکربندی Corosync”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”معرفی Corosync و نقش آن در ارتباط بین گره‌های کلاستر” subtitle=”توضیحات کامل”]Corosync یکی از اجزای کلیدی در ایجاد کلاسترهای در دسترس بالا (HA) است که وظیفه مدیریت ارتباطات بین گره‌های کلاستر را بر عهده دارد. این ابزار به عنوان یک لایه ارتباطی در کلاسترهای مبتنی بر Pacemaker عمل کرده و تضمین می‌کند که تمامی گره‌های کلاستر از وضعیت یکدیگر آگاه باشند.

Corosync برای مدیریت ارتباطات بین گره‌های کلاستر از پروتکل‌های پیام‌رسانی و هماهنگ‌سازی توزیع‌شده استفاده می‌کند. این ابزار امکان انتقال اطلاعات حیاتی مانند وضعیت گره‌ها، اعلان خرابی و هماهنگی بین سرویس‌های کلاستر را فراهم می‌کند.

---

ویژگی‌های کلیدی Corosync

• پشتیبانی از پیام‌رسانی قابل اطمینان: Corosync از یک پروتکل چندپخشی (Multicast) یا یک‌به‌یک (Unicast) برای ارسال پیام‌های بین گره‌ها استفاده می‌کند.
• تشخیص خرابی گره‌ها: با استفاده از الگوریتم‌های Heartbeat و Membership، خرابی گره‌ها را شناسایی کرده و برای مدیریت صحیح، وضعیت آن‌ها را به Pacemaker گزارش می‌دهد.
• پشتیبانی از چندین رابط شبکه: امکان استفاده از چندین اینترفیس شبکه برای افزایش افزونگی و کاهش احتمال از دست رفتن ارتباطات.
• مدیریت گروهی منابع: Corosync امکان مدیریت هم‌زمان چندین گره و همگام‌سازی تنظیمات بین آن‌ها را فراهم می‌کند.
• استفاده از Token-Based Mechanism: Corosync از سیستم Token Ring برای حفظ یکپارچگی در ارتباطات گره‌ها استفاده می‌کند که مانع از ارسال پیام‌های متناقض می‌شود.

---

نقش Corosync در ارتباط بین گره‌های کلاستر

Corosync مسئولیت مدیریت ارتباطات داخلی کلاستر را دارد و با Pacemaker هماهنگ می‌شود تا عملکرد صحیح کلاستر تضمین گردد. در این فرآیند، Corosync وظایف زیر را انجام می‌دهد:

1. تشخیص و نظارت بر وضعیت گره‌ها: هر گره در کلاستر به‌صورت مداوم پیام‌هایی را برای سایر گره‌ها ارسال می‌کند تا حضور خود را اعلام کند. در صورتی که پیام از یک گره دریافت نشود، آن گره به‌عنوان خراب (Failed) در نظر گرفته می‌شود.
2. مدیریت عضویت گره‌ها: Corosync مسئول به‌روز نگه‌داشتن لیست گره‌های فعال در کلاستر است. در صورت اضافه یا حذف شدن یک گره، این تغییرات به سایر گره‌ها اطلاع داده می‌شود.
3. توزیع تغییرات پیکربندی: هر تغییری که در پیکربندی کلاستر ایجاد شود، Corosync آن را به تمامی گره‌ها منتقل کرده و همگام‌سازی می‌کند.
4. ارسال داده‌های وضعیت گره‌ها به Pacemaker: Corosync اطلاعات مربوط به وضعیت گره‌ها را به مدیر منابع کلاستر (Pacemaker) ارسال می‌کند تا در صورت خرابی، فرآیند Failover انجام شود.

---

پیکربندی اولیه Corosync

برای راه‌اندازی Corosync، ابتدا باید پکیج‌های لازم را روی تمامی گره‌های کلاستر نصب کنیم:

sudo apt update && sudo apt install -y corosync pacemaker

یا در توزیع‌های مبتنی بر RHEL:

sudo yum install -y corosync pacemaker

پس از نصب، فایل پیکربندی Corosync در مسیر زیر قرار دارد:

/etc/corosync/corosync.conf

برای تعریف گره‌های کلاستر و تنظیمات ارتباطی، این فایل باید ویرایش شود. یک نمونه تنظیم اولیه:

sudo nano /etc/corosync/corosync.conf

و سپس مقداردهی اولیه این فایل به‌صورت زیر خواهد بود:

totem {
    version: 2
    cluster_name: ha_cluster
    transport: udpu
    token: 3000
    interface {
        ringnumber: 0
        bindnetaddr: 192.168.1.0
        mcastport: 5405
    }
}

nodelist {
    node {
        ring0_addr: 192.168.1.1
        nodeid: 1
    }
    node {
        ring0_addr: 192.168.1.2
        nodeid: 2
    }
}

quorum {
    provider: corosync_votequorum
}

• cluster_name: نام کلاستر را مشخص می‌کند.
• transport: نحوه انتقال داده‌ها (UDP Unicast یا Multicast).
• bindnetaddr: محدوده آدرس شبکه‌ای که گره‌ها در آن قرار دارند.
• ring0_addr: آدرس IP هر گره.
• quorum: مکانیزم رأی‌گیری برای جلوگیری از Split-Brain.

پس از انجام تغییرات، سرویس Corosync باید راه‌اندازی مجدد شود:

sudo systemctl restart corosync
sudo systemctl enable corosync

و وضعیت سرویس بررسی شود:

sudo systemctl status corosync

---

جمع‌بندی

Corosync یکی از اجزای حیاتی در کلاسترهای HA است که وظیفه مدیریت ارتباطات و همگام‌سازی بین گره‌های کلاستر را بر عهده دارد. این ابزار با استفاده از پروتکل‌های پیام‌رسانی قابل اطمینان، وضعیت گره‌ها را به Pacemaker ارسال کرده و در صورت خرابی یک گره، امکان مدیریت منابع و فرآیند Failover را فراهم می‌کند.

در این بخش، نحوه عملکرد Corosync، ویژگی‌های آن و تنظیمات اولیه معرفی شد. در ادامه، به بررسی دقیق‌تر پیکربندی Pacemaker و هماهنگ‌سازی آن با Corosync خواهیم پرداخت.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نصب Corosync بر روی هر یک از گره‌های کلاستر” subtitle=”توضیحات کامل”]برای راه‌اندازی یک کلاستر در دسترس بالا (HA)، اولین گام نصب Corosync روی تمامی گره‌های کلاستر است. Corosync مسئولیت مدیریت ارتباطات بین گره‌ها، نظارت بر وضعیت آن‌ها و اطلاع‌رسانی تغییرات به Pacemaker را بر عهده دارد.

---

پیش‌نیازهای نصب Corosync

قبل از نصب، موارد زیر باید بررسی و انجام شوند:

1. حداقل دو گره برای کلاستر در نظر گرفته شود.
2. همه گره‌ها دارای نام میزبان (hostname) منحصربه‌فرد و قابل حل در شبکه باشند.
3. همه گره‌ها به یکدیگر از طریق SSH دسترسی داشته باشند.
4. فایروال به‌درستی پیکربندی شده باشد تا ارتباط بین گره‌ها مسدود نشود.
5. بسته‌های موردنیاز برای کلاستر نصب شوند.

---

نصب Corosync در توزیع‌های مختلف

نصب در Debian/Ubuntu

در هر گره، دستورات زیر را اجرا کنید:

sudo apt update && sudo apt install -y corosync pacemaker

نصب در RHEL/CentOS

ابتدا مخازن High Availability را فعال کنید:

sudo yum install -y epel-release
sudo yum install -y corosync pacemaker

نصب در Rocky Linux/AlmaLinux

sudo dnf install -y corosync pacemaker

پس از نصب، بررسی کنید که بسته‌های موردنیاز به‌درستی نصب شده‌اند:

rpm -qa | grep corosync

یا در Debian/Ubuntu:

dpkg -l | grep corosync

---

تنظیمات اولیه شبکه بین گره‌های کلاستر

هر گره باید یک آدرس IP ثابت در شبکه داشته باشد. برای اطمینان از دسترسی بین گره‌ها، ابتدا بررسی کنید که هاست‌های دیگر در شبکه قابل دسترسی باشند:

ping -c 3 node2

اگر نام گره‌ها به‌درستی حل نمی‌شود، در هر گره فایل /etc/hosts را ویرایش کنید:

sudo nano /etc/hosts

و خطوط زیر را اضافه کنید (با توجه به آدرس‌های IP واقعی گره‌ها):

192.168.1.1 node1
192.168.1.2 node2
192.168.1.3 node3

---

فعال‌سازی و بررسی سرویس Corosync

پس از نصب، سرویس Corosync را فعال و بررسی کنید:

sudo systemctl enable corosync --now
sudo systemctl status corosync

اگر سرویس به‌درستی اجرا نشده باشد، لاگ‌های مربوط به آن را بررسی کنید:

sudo journalctl -xe -u corosync

---

جمع‌بندی

در این بخش، نحوه نصب Corosync بر روی گره‌های کلاستر در توزیع‌های مختلف توضیح داده شد. پس از نصب، اطمینان از اتصال صحیح بین گره‌ها و تنظیم آدرس‌های شبکه برای عملکرد صحیح کلاستر ضروری است. در ادامه، به پیکربندی فایل corosync.conf و راه‌اندازی کلاستر خواهیم پرداخت.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”پیکربندی فایل‌های اصلی Corosync (corosync.conf)” subtitle=”توضیحات کامل”]پس از نصب Corosync، گام بعدی پیکربندی فایل corosync.conf برای تعریف نحوه ارتباط بین گره‌های کلاستر است. این فایل مشخص می‌کند که گره‌ها چگونه با یکدیگر ارتباط برقرار می‌کنند، چه تنظیماتی برای شبکه استفاده می‌شود و چه مکانیزم‌هایی برای بررسی سلامت گره‌ها اعمال می‌شود.

---

مسیر و ساختار فایل پیکربندی

فایل پیکربندی Corosync در مسیر زیر قرار دارد:

/etc/corosync/corosync.conf

برای ویرایش این فایل، از یک ویرایشگر متنی استفاده کنید:

sudo nano /etc/corosync/corosync.conf

---

تنظیمات کلیدی در corosync.conf

یک نمونه فایل corosync.conf شامل بخش‌های زیر است:

totem {
    version: 2
    cluster_name: my_cluster
    transport: udpu
    token: 3000
    token_retransmits_before_loss_const: 10
    join: 60
    consensus: 7500
    max_messages: 20
    interface {
        ringnumber: 0
        bindnetaddr: 192.168.1.0
        mcastport: 5405
        ttl: 1
    }
}

nodelist {
    node {
        ring0_addr: 192.168.1.1
        nodeid: 1
    }
    node {
        ring0_addr: 192.168.1.2
        nodeid: 2
    }
    node {
        ring0_addr: 192.168.1.3
        nodeid: 3
    }
}

quorum {
    provider: corosync_votequorum
    two_node: 1
}

logging {
    to_logfile: yes
    logfile: /var/log/corosync/corosync.log
    to_syslog: yes
    timestamp: on
}

---

توضیح بخش‌های مختلف پیکربندی

۱. بخش totem

این بخش نحوه ارتباط بین گره‌های کلاستر را مشخص می‌کند:

• cluster_name: نام کلاستر را تعیین می‌کند.
• transport: پروتکل ارتباطی را مشخص می‌کند (udpu برای یونیکست و rrp برای دوحلقه‌ای).
• bindnetaddr: آدرس شبکه برای ارتباط گره‌ها (باید اولین سه عدد IP گره‌ها باشد).
• mcastport: پورت مورد استفاده برای ارتباط.
• ttl: مقدار TTL بسته‌های شبکه.

۲. بخش nodelist

این قسمت لیست گره‌های موجود در کلاستر را مشخص می‌کند. هر گره باید دارای آدرس IP مشخص و یک شناسه (nodeid) یکتا باشد.

۳. بخش quorum

مدیریت حد نصاب (quorum) که مشخص می‌کند کلاستر چگونه تصمیم‌گیری کند وقتی برخی از گره‌ها از دسترس خارج می‌شوند.

• provider: corosync_votequorum: تعیین مکانیزم رای‌گیری برای quorum.
• two_node: 1: برای کلاسترهای دوگرهی، quorum را غیرفعال می‌کند.

۴. بخش logging

این بخش تنظیمات مربوط به لاگ‌ها را مشخص می‌کند:

• to_logfile: yes → فعال‌سازی لاگ در فایل.
• logfile: /var/log/corosync/corosync.log → مسیر ذخیره لاگ‌ها.
• to_syslog: yes → ارسال لاگ‌ها به syslog.

---

کپی فایل پیکربندی به سایر گره‌ها

پس از انجام تنظیمات در گره اول، باید فایل را به سایر گره‌های کلاستر کپی کنید:

scp /etc/corosync/corosync.conf root@node2:/etc/corosync/corosync.conf
scp /etc/corosync/corosync.conf root@node3:/etc/corosync/corosync.conf

---

راه‌اندازی مجدد Corosync و بررسی وضعیت

بعد از پیکربندی، سرویس Corosync را روی تمامی گره‌ها ریستارت کنید:

sudo systemctl restart corosync
sudo systemctl status corosync

برای بررسی ارتباط بین گره‌ها، از دستور زیر استفاده کنید:

sudo corosync-cmapctl | grep members

خروجی باید لیست تمامی گره‌های کلاستر را نمایش دهد.

---

جمع‌بندی

در این بخش، نحوه پیکربندی فایل corosync.conf برای ارتباط بین گره‌های کلاستر توضیح داده شد. این فایل مکانیزم ارتباطی، quorum، لاگ‌ها و لیست گره‌ها را مشخص می‌کند. پس از پیکربندی، باید فایل را در تمامی گره‌ها کپی کرده و سرویس Corosync را ریستارت و بررسی کنیم تا ارتباط گره‌ها برقرار باشد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تنظیمات برای انتخاب پروتکل‌های ارتباطی (مانند UDP و TCP)” subtitle=”توضیحات کامل”]در Corosync، پروتکل‌های ارتباطی برای تبادل پیام‌ها بین گره‌های کلاستر قابل تنظیم هستند. انتخاب مناسب بین UDP و TCP به نیازهای شبکه و ساختار کلاستر بستگی دارد.

---

انتخاب پروتکل ارتباطی در Corosync

در بخش totem از فایل /etc/corosync/corosync.conf، می‌توان پروتکل ارتباطی را مشخص کرد. دو گزینه اصلی برای تنظیمات ارتباطی عبارت‌اند از:

1. UDP Unicast (UDPU)
2. Redundant Ring Protocol (RRP) – برای ارتباط چندحلقه‌ای (UDP Multicast یا Unicast)

---

۱. استفاده از UDP Unicast (UDPU)

UDP گزینه‌ای سریع و سبک برای ارتباط بین گره‌ها است و برای کلاسترهایی که تعداد کمی گره دارند، مناسب است. برای استفاده از UDP Unicast، بخش totem را به‌صورت زیر پیکربندی کنید:

totem {
    version: 2
    cluster_name: my_cluster
    transport: udpu
    token: 3000
    token_retransmits_before_loss_const: 10
    join: 60
    consensus: 7500
    max_messages: 20
    interface {
        ringnumber: 0
        bindnetaddr: 192.168.1.0
        mcastport: 5405
        ttl: 1
    }
}

پارامترهای کلیدی:

• transport: udpu → استفاده از UDP Unicast برای ارتباط بین گره‌ها.
• bindnetaddr: 192.168.1.0 → مشخص کردن شبکه‌ای که گره‌ها در آن حضور دارند.
• mcastport: 5405 → پورت مورد استفاده برای ارتباط.
• ttl: 1 → مقدار TTL برای بسته‌های ارسالی در شبکه.

💡 نکته: در این روش، باید لیست تمام گره‌های کلاستر را در nodelist مشخص کنید، زیرا برخلاف Multicast، هر گره مستقیماً با گره‌های دیگر ارتباط برقرار می‌کند.

---

۲. استفاده از Redundant Ring Protocol (RRP) با UDP Multicast

اگر کلاستر دارای چندین شبکه است و نیاز به تحمل خرابی (fault tolerance) بیشتری دارید، می‌توانید از RRP استفاده کنید که حلقه‌های اضافی برای ارتباط را فراهم می‌کند.

نمونه تنظیمات برای UDP Multicast:

totem {
    version: 2
    cluster_name: my_cluster
    transport: udp
    token: 3000
    token_retransmits_before_loss_const: 10
    join: 60
    consensus: 7500
    max_messages: 20
    interface {
        ringnumber: 0
        bindnetaddr: 192.168.1.0
        mcastaddr: 239.255.1.1
        mcastport: 5405
        ttl: 1
    }
    interface {
        ringnumber: 1
        bindnetaddr: 10.0.0.0
        mcastaddr: 239.255.2.1
        mcastport: 5406
        ttl: 1
    }
}

پارامترهای کلیدی:

• transport: udp → استفاده از UDP Multicast برای ارتباط بین گره‌ها.
• mcastaddr: 239.255.1.1 → آدرس Multicast که تمام گره‌ها از آن استفاده خواهند کرد.
• mcastport: 5405 → پورت اختصاصی برای Multicast.
• ringnumber: 0 و ringnumber: 1 → تعریف دو حلقه ارتباطی برای افزایش تحمل خرابی.

💡 نکته: UDP Multicast به پشتیبانی سخت‌افزاری و تنظیمات شبکه نیاز دارد. برخی از شبکه‌ها (به‌خصوص در سرورهای ابری) ممکن است Multicast را مسدود کنند.

---

۳. استفاده از TCP (Experimental Feature)

به‌صورت پیش‌فرض، Corosync از TCP پشتیبانی نمی‌کند، اما در نسخه‌های جدیدتر، برخی قابلیت‌های آزمایشی برای استفاده از TCP اضافه شده‌اند.

برای فعال‌سازی TCP در Corosync، می‌توان در بخش totem مقدار transport را روی tcp تنظیم کرد:

totem {
    version: 2
    cluster_name: my_cluster
    transport: tcp
    token: 3000
    token_retransmits_before_loss_const: 10
    join: 60
    consensus: 7500
    max_messages: 20
    interface {
        ringnumber: 0
        bindnetaddr: 192.168.1.0
        port: 5405
    }
}

پارامترهای کلیدی:

• transport: tcp → فعال‌سازی TCP برای ارتباط بین گره‌ها.
• port: 5405 → مشخص کردن پورت برای ارتباطات TCP.

💡 نکته: این قابلیت هنوز به‌اندازه UDP پایدار نیست و ممکن است در برخی سناریوها مشکلاتی ایجاد کند.

---

کپی فایل پیکربندی به سایر گره‌ها

پس از تغییرات در فایل پیکربندی، باید آن را روی تمام گره‌های کلاستر کپی کنید:

scp /etc/corosync/corosync.conf root@node2:/etc/corosync/corosync.conf
scp /etc/corosync/corosync.conf root@node3:/etc/corosync/corosync.conf

---

راه‌اندازی مجدد سرویس Corosync

پس از پیکربندی پروتکل ارتباطی، Corosync را در تمامی گره‌ها ریستارت کنید:

sudo systemctl restart corosync
sudo systemctl status corosync

برای بررسی صحت ارتباط بین گره‌ها:

sudo corosync-cmapctl | grep members

---

جمع‌بندی

• UDP Unicast (UDPU) → برای کلاسترهای کوچک مناسب است و نیازی به پشتیبانی Multicast در شبکه ندارد.
• UDP Multicast (RRP) → برای تحمل خرابی بیشتر مناسب است، اما نیاز به پشتیبانی شبکه از Multicast دارد.
• TCP (Experimental) → در نسخه‌های جدید اضافه شده ولی هنوز کاملاً پایدار نیست.

بسته به زیرساخت شبکه و نیازهای کلاستر، می‌توان بهترین گزینه را انتخاب و در فایل corosync.conf تنظیم کرد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”بررسی و تست اتصال گره‌ها از طریق Corosync” subtitle=”توضیحات کامل”]پس از راه‌اندازی Corosync و پیکربندی ارتباط بین گره‌های کلاستر، بررسی صحت اتصال بین گره‌ها ضروری است. این کار با استفاده از چندین ابزار داخلی و دستورات لینوکسی انجام می‌شود.

---

۱. بررسی وضعیت سرویس Corosync در هر گره

در هر گره، ابتدا بررسی کنید که سرویس Corosync به درستی اجرا شده باشد:

sudo systemctl status corosync

اگر سرویس فعال نباشد، آن را راه‌اندازی کنید:

sudo systemctl restart corosync

و برای اطمینان از فعال بودن در زمان بوت:

sudo systemctl enable corosync

---

۲. بررسی لیست گره‌های متصل

با استفاده از دستور زیر می‌توانید لیست گره‌های عضو در کلاستر را مشاهده کنید:

sudo corosync-cmapctl | grep members

خروجی نمونه:

runtime.totem.pg.mrp.srp.members.1.config_version (u32) = 2
runtime.totem.pg.mrp.srp.members.1.ip (str) = 192.168.1.1
runtime.totem.pg.mrp.srp.members.2.config_version (u32) = 2
runtime.totem.pg.mrp.srp.members.2.ip (str) = 192.168.1.2

در اینجا، آدرس‌های IP گره‌های عضو نمایش داده شده است.

---

۳. تست ارتباط بین گره‌ها با ابزار corosync-cmapctl

می‌توان بررسی کرد که آیا ارتباط بین گره‌ها برقرار است یا خیر:

sudo corosync-cmapctl | grep runtime.totem.pg.mrp.srp.members

اگر همه گره‌ها نمایش داده شوند، یعنی ارتباط بین آن‌ها برقرار است.

---

۴. تست ارسال و دریافت پیام بین گره‌ها

ابزار corosync-qnetd می‌تواند بررسی کند که آیا گره‌ها می‌توانند پیام ارسال و دریافت کنند. برای اجرای تست، دستور زیر را در یکی از گره‌ها اجرا کنید:

sudo corosync-cmapctl | grep rrp

اگر مقدار rrp.active برابر با 1 باشد، یعنی ارتباط بین گره‌ها فعال است.

---

۵. بررسی صحت دریافت پیام‌ها با corosync-objctl

با استفاده از دستور زیر می‌توان بررسی کرد که آیا پیام‌های Corosync به درستی بین گره‌ها منتقل می‌شوند:

sudo corosync-objctl | grep member

خروجی باید شامل لیست گره‌های متصل باشد.

---

۶. تست ارتباط شبکه‌ای بین گره‌ها

۶.۱ بررسی ارتباط از طریق پینگ

در هر گره، ارتباط با سایر گره‌ها را بررسی کنید:

ping -c 4 192.168.1.2

۶.۲ بررسی باز بودن پورت Corosync (۵۴۰۵ یا مقدار مشخص‌شده در corosync.conf)

در گره اول، بررسی کنید که آیا پورت Corosync باز است:

sudo netstat -tunlp | grep 5405

اگر خروجی شامل corosync باشد، یعنی پورت موردنظر باز است.

در گره دوم، بررسی کنید که آیا می‌توان به پورت Corosync متصل شد:

nc -zv 192.168.1.1 5405

خروجی باید Connection successful باشد.

---

۷. بررسی لاگ‌های Corosync برای ارورها

در صورت وجود مشکل، بررسی لاگ‌ها می‌تواند اطلاعات مهمی ارائه دهد:

sudo journalctl -u corosync --no-pager | tail -n 50

یا در مسیر لاگ‌های سیستمی:

sudo cat /var/log/corosync.log | tail -n 50

---

۸. تست مجدد بعد از اعمال تغییرات

اگر بعد از انجام این تست‌ها، مشکلی در ارتباطات وجود داشت، بهتر است:

1. تنظیمات فایل corosync.conf را بررسی کنید و مطمئن شوید که مقدار bindnetaddr درست تنظیم شده است.
2. سرویس را در تمام گره‌ها ری‌استارت کنید:

sudo systemctl restart corosync

3. از ابزار tcpdump برای بررسی بسته‌های دریافتی استفاده کنید:

sudo tcpdump -i eth0 port 5405

---

جمع‌بندی

• بررسی وضعیت سرویس Corosync و اطمینان از اجرا بودن آن در تمامی گره‌ها.
• استفاده از corosync-cmapctl و corosync-objctl برای مشاهده گره‌های متصل.
• تست ارتباط پینگ، بررسی باز بودن پورت ۵۴۰۵، و استفاده از tcpdump برای مشاهده بسته‌های ارسالی.
• بررسی لاگ‌های سیستم برای یافتن خطاهای احتمالی.

با اجرای این تست‌ها، می‌توان از صحت عملکرد Corosync در ارتباط بین گره‌های کلاستر اطمینان حاصل کرد.[/cdb_course_lesson][cdb_course_lesson title=”فصل 2. نصب و پیکربندی Pacemaker”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”معرفی Pacemaker و وظیفه آن به عنوان مدیر منابع کلاستر” subtitle=”توضیحات کامل”]Pacemaker یک ابزار متن‌باز است که به عنوان مدیر منابع کلاستر (Cluster Resource Manager یا CRM) عمل می‌کند و برای ایجاد و مدیریت کلاسترهای پر در دسترس (High Availability) طراحی شده است. این ابزار به طور ویژه برای اطمینان از پایداری و عملکرد صحیح سرویس‌ها در محیط‌های توزیع‌شده و کلاسترهای چندین سرور کاربرد دارد. Pacemaker معمولاً در کنار ابزارهایی مانند Corosync (برای هماهنگی کلاستر) و OpenAIS (برای ایجاد ارتباطات بین نودهای کلاستر) استفاده می‌شود.

وظایف اصلی Pacemaker به عنوان مدیر منابع کلاستر:

1. مدیریت منابع کلاستر:
   Pacemaker مسئول مدیریت منابع موجود در کلاستر است. این منابع می‌توانند شامل سرویس‌ها، برنامه‌ها، دستگاه‌های ذخیره‌سازی و حتی شبکه‌ها باشند. Pacemaker منابع را بررسی کرده و مطمئن می‌شود که هر کدام در جای مناسب خود قرار دارند و در صورت بروز مشکل، انتقال داده‌ها و منابع را به نودهای سالم‌تر انجام می‌دهد.
2. اجرای سرویس‌ها در نودهای مختلف:
   Pacemaker به طور خودکار سرویس‌ها را بین نودهای مختلف کلاستر توزیع می‌کند. این ویژگی باعث می‌شود که در صورت بروز خرابی در یک نود، سرویس‌ها به نودهای سالم‌تر منتقل شوند و از توقف خدمات جلوگیری گردد.
3. نظارت بر وضعیت منابع:
   Pacemaker با استفاده از منابع مختلف، وضعیت سلامت نودها و سرویس‌ها را به صورت پیوسته نظارت می‌کند. در صورتی که مشکلی شبیه خرابی در یکی از نودها یا سرویس‌ها بروز کند، Pacemaker به طور خودکار برای رفع مشکل اقدام می‌کند.
4. تعادل بار (Load Balancing):
   Pacemaker می‌تواند بار کاری را بین نودهای مختلف توزیع کند. این عملکرد به ویژه در کلاسترهای بزرگ و با بار کاری سنگین بسیار مفید است.
5. پشتیبانی از سیاست‌های Failover و Fencing:
   در صورت بروز خرابی در یکی از نودهای کلاستر، Pacemaker به طور خودکار سیاست‌های failover را اجرا کرده و منابع و سرویس‌ها را به نودهای سالم منتقل می‌کند. همچنین، از fencing برای جلوگیری از آسیب به داده‌ها استفاده می‌کند، به این معنا که اگر یک نود به درستی عمل نکند، دسترسی آن به منابع قطع می‌شود.
6. سیاست‌های HA (High Availability):
   Pacemaker بر اساس سیاست‌های خاص خود، سعی در فراهم کردن در دسترس بودن بالا (High Availability) برای سرویس‌ها دارد. این ابزار به شما این امکان را می‌دهد که در صورتی که یک نود دچار خرابی شود، سیستم به صورت خودکار سرویس‌ها را به نودهای سالم‌تر منتقل کند.
7. پیکربندی و مدیریت کلاستر:
   Pacemaker از پیکربندی‌های متنوعی برای مدیریت کلاسترها پشتیبانی می‌کند. این ابزار به مدیران سیستم این امکان را می‌دهد که کلاستر خود را به صورت کارآمد و مطابق با نیازهای خاص پیکربندی کنند.

اجزای اصلی Pacemaker:

1. Cluster Resource Manager (CRM):
   این قسمت از Pacemaker مسئول نظارت و مدیریت بر منابع و سرویس‌های موجود در کلاستر است.
2. Resource Agents (RA):
   این اجزا وظیفه نظارت و مدیریت هر نوع منبع خاص را در کلاستر به عهده دارند. برای هر نوع منبع (مانند سرویس‌ها یا دستگاه‌های ذخیره‌سازی) یک Resource Agent مخصوص وجود دارد.
3. Corosync:
   Pacemaker به طور معمول با Corosync برای هماهنگی ارتباطات و نظارت بر وضعیت نودهای مختلف در کلاستر همکاری می‌کند.
4. Fence Devices:
   این اجزا به طور خودکار در صورتی که یک نود دچار مشکل شود، دسترسی آن را به منابع قطع می‌کنند تا از هرگونه آسیب به داده‌ها یا سیستم جلوگیری شود.

چگونگی نصب و پیکربندی Pacemaker:

برای نصب و پیکربندی Pacemaker، می‌توانید از دستورات زیر استفاده کنید. مسیر فایل‌های پیکربندی در این مثال‌ها آورده شده است.

1. نصب Pacemaker:

ابتدا باید Pacemaker را نصب کنید. برای سیستم‌عامل‌های مبتنی بر دیب این دستور را اجرا کنید:

sudo apt-get update
sudo apt-get install pacemaker

برای سیستم‌های مبتنی بر ردهت:

sudo yum install pacemaker

2. پیکربندی کلاستر با Corosync:

پس از نصب، باید Corosync را برای برقراری ارتباط میان نودهای کلاستر پیکربندی کنید. فایل پیکربندی Corosync معمولاً در مسیر /etc/corosync/corosync.conf قرار دارد. نمونه‌ای از پیکربندی Corosync:

totem {
    version: 2
    secauth: on
    threads: 0
    interface {
        ringnumber: 0
        bindnetaddr: 192.168.1.0
        mcastaddr: 239.255.1.1
        mcastport: 5405
    }
}

3. راه‌اندازی Pacemaker:

پس از نصب و پیکربندی Corosync، می‌توانید Pacemaker را با دستور زیر شروع کنید:

sudo systemctl start pacemaker

برای اطمینان از عملکرد صحیح، وضعیت Pacemaker را بررسی کنید:

sudo crm status

جمع بندی

Pacemaker به عنوان مدیر منابع کلاستر، به مدیران سیستم این امکان را می‌دهد که کلاسترهای پر در دسترس و مقاوم در برابر خرابی‌ها ایجاد کنند. این ابزار با نظارت مستمر بر منابع و سرویس‌ها، به‌طور خودکار انتقال منابع و سرویس‌ها را در صورت خرابی انجام می‌دهد و از وقوع قطعی در سیستم‌ها جلوگیری می‌کند. تنظیمات و پیکربندی‌های دقیق Pacemaker برای هر نوع محیط کلاستری می‌تواند به بهبود عملکرد و کاهش ریسک خرابی‌ها کمک کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نصب Pacemaker بر روی تمامی گره‌های کلاستر” subtitle=”توضیحات کامل”]برای استفاده از Pacemaker در یک کلاستر HA (High Availability)، باید این ابزار را بر روی تمامی گره‌های کلاستر نصب و پیکربندی کنید. در این قسمت، مراحل نصب Pacemaker را به صورت گام به گام بر روی تمامی گره‌ها توضیح خواهیم داد.

پیش‌نیازها

قبل از نصب Pacemaker، اطمینان حاصل کنید که Corosync (ابزار هماهنگ‌سازی کلاستر) و Pacemaker در تمامی گره‌ها نصب شده باشد. این دو ابزار باید به درستی پیکربندی شوند تا ارتباط بین گره‌های کلاستر برقرار شود.

مراحل نصب Pacemaker

1. نصب Pacemaker و Corosync بر روی گره‌های کلاستربرای نصب Pacemaker و Corosync ابتدا باید به طور جداگانه این دو ابزار را بر روی هر گره نصب کنید.برای سیستم‌های مبتنی بر دیب (مثل Ubuntu و Debian):

   sudo apt-get update
   sudo apt-get install pacemaker corosync
   

   برای سیستم‌های مبتنی بر ردهت (مثل CentOS و RHEL):

   sudo yum install pacemaker corosync
   

2. پیکربندی CorosyncCorosync برای ایجاد ارتباط بین گره‌های کلاستر ضروری است. فایل پیکربندی Corosync معمولاً در مسیر /etc/corosync/corosync.conf قرار دارد. این فایل باید در تمامی گره‌ها مشابه باشد.یک مثال ساده از پیکربندی Corosync:

   totem {
       version: 2
       secauth: on
       threads: 0
       interface {
           ringnumber: 0
           bindnetaddr: 192.168.1.0
           mcastaddr: 239.255.1.1
           mcastport: 5405
       }
   }
   

   توجه داشته باشید که bindnetaddr باید به شبکه محلی شما اشاره کند و mcastaddr آدرس پخش چندگانه‌ای است که برای ارتباطات در کلاستر استفاده می‌شود.

3. راه‌اندازی و فعال‌سازی Pacemakerپس از نصب و پیکربندی Corosync، باید سرویس Pacemaker را راه‌اندازی کنید.برای شروع سرویس Pacemaker، دستور زیر را اجرا کنید:

   sudo systemctl start pacemaker
   

   برای اطمینان از این که Pacemaker به درستی کار می‌کند، وضعیت سرویس را با دستور زیر بررسی کنید:

   sudo systemctl status pacemaker
   

   همچنین برای راه‌اندازی خودکار Pacemaker در زمان بوت، دستور زیر را اجرا کنید:

   sudo systemctl enable pacemaker
   

4. اتصال گره‌ها به کلاسترپس از نصب و راه‌اندازی Pacemaker بر روی تمامی گره‌ها، باید گره‌ها را به یکدیگر متصل کنید. برای این کار، از دستور crm استفاده می‌شود.بر روی اولین گره، دستور زیر را اجرا کنید تا یک کلاستر جدید راه‌اندازی کنید:

   sudo crm cluster start
   

   سپس، برای پیوستن سایر گره‌ها به کلاستر، از دستور زیر استفاده کنید:

   sudo crm cluster join
   

5. بررسی وضعیت کلاستربرای بررسی وضعیت کلی کلاستر و اطمینان از این که تمامی گره‌ها به درستی به هم متصل شده‌اند، از دستور زیر استفاده کنید:

   sudo crm status
   

   این دستور وضعیت گره‌ها، منابع و سرویس‌های موجود را نمایش می‌دهد.

جمع‌بندی

نصب و پیکربندی Pacemaker بر روی تمامی گره‌های کلاستر برای ایجاد یک کلاستر با دسترسی بالا و مقاوم در برابر خرابی‌ها ضروری است. پس از نصب و پیکربندی Corosync و Pacemaker، گره‌ها به هم متصل شده و می‌توانند منابع و سرویس‌ها را به‌طور خودکار مدیریت کنند. این ابزارها به مدیران سیستم این امکان را می‌دهند که از بروز مشکلات ناشی از خرابی‌های سخت‌افزاری جلوگیری کرده و در صورت نیاز، سرویس‌ها را به گره‌های سالم‌تر منتقل کنند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تنظیمات اولیه Pacemaker و بررسی وضعیت آن” subtitle=”توضیحات کامل”]پس از نصب و راه‌اندازی Pacemaker، تنظیمات اولیه آن برای اطمینان از عملکرد صحیح کلاستر و منابع لازم است. این تنظیمات به طور معمول شامل پیکربندی‌های مربوط به منابع، تعیین سیاست‌های کلسترینگ و پیکربندی زمان‌بندی عملیات‌های مختلف می‌شود.

در این بخش، مراحل تنظیمات اولیه Pacemaker را به همراه نحوه بررسی وضعیت آن شرح خواهیم داد.

1. پیکربندی اولیه Pacemaker

برای پیکربندی اولیه Pacemaker، از ابزار crm یا pcs استفاده می‌شود. ابزار crm برای انجام عملیات‌های مختلف کلاسترینگ مانند مدیریت منابع، وضعیت گره‌ها و سیاست‌های فیلتر استفاده می‌شود.

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

1. بررسی وضعیت کلاستر:دستور زیر برای بررسی وضعیت کلی کلاستر و اطمینان از صحت عملکرد آن استفاده می‌شود:

   sudo crm status
   

   این دستور لیستی از وضعیت گره‌ها، منابع و سرویس‌های در حال اجرا در کلاستر نمایش می‌دهد.

2. نمایش وضعیت منابع:برای مشاهده وضعیت منابع در کلاستر، می‌توان از دستور زیر استفاده کرد:

   sudo crm resource status
   

   این دستور منابع فعلی کلاستر و وضعیت آن‌ها را به شما نشان می‌دهد.

2. تنظیمات اولیه منابع

برای تنظیم و مدیریت منابع در Pacemaker، از دستورات مربوط به منابع (مثل سرویس‌ها یا دیسک‌ها) استفاده می‌شود. یکی از منابع مهم در کلاسترهای HA، سرویس‌ها و منابع شبیه به آن‌ها هستند که باید تنظیم شوند.

برای مثال، برای اضافه کردن یک سرویس به کلاستر، از دستور زیر استفاده می‌شود:

sudo crm configure primitive <resource_name> ocf:heartbeat:IPaddr2 \
    params ip=<ip_address> cidr_netmask=24 \
    op monitor interval="30s"

در این دستور:

• <resource_name> نام منبع است.
• ocf:heartbeat:IPaddr2 نوع منبع است که یک IP مجازی را مدیریت می‌کند.
• params ip=<ip_address> آدرس IP برای منبع را تنظیم می‌کند.
• op monitor interval="30s" دستور مانیتورینگ منابع را با فواصل زمانی ۳۰ ثانیه تنظیم می‌کند.

3. تنظیمات فیلتر

یکی از بخش‌های مهم در پیکربندی Pacemaker، تنظیم فیلترها برای منابع است. فیلترها به شما این امکان را می‌دهند که سیاست‌های خاصی را برای توزیع منابع در کلاستر پیاده‌سازی کنید.

برای ایجاد فیلتر، می‌توان از دستور زیر استفاده کرد:

sudo crm configure property stonith-enabled=false

این دستور STONITH (Shoot The Other Node In The Head) را غیرفعال می‌کند که این ویژگی در مواردی که کلاستر نیاز به مقابله با خرابی گره‌ها دارد، استفاده می‌شود.

4. راه‌اندازی مانیتورینگ منابع

Pacemaker به طور پیش‌فرض منابع کلاستر را با استفاده از ابزارهایی مانند crm یا pcs به صورت دوره‌ای مانیتور می‌کند. به‌طور کلی، هر منبع باید به طور مداوم بررسی شود تا از درستی عملکرد آن اطمینان حاصل شود.

برای تنظیم مانیتورینگ منابع در Pacemaker، دستور زیر استفاده می‌شود:

sudo crm configure primitive <resource_name> ocf:heartbeat:Dummy \
    op monitor interval="60s"

این دستور یک منبع شبیه‌سازی‌شده (Dummy) را با مانیتورینگ دوره‌ای 60 ثانیه‌ای راه‌اندازی می‌کند.

5. فعال‌سازی و بررسی سیاست‌های High Availability (HA)

برای فعال‌سازی سیاست‌های HA در Pacemaker، می‌توان از دستور زیر استفاده کرد:

sudo crm configure colocation <resource_name> with <resource_name2> INFINITY

این دستور منابع را به‌طور مداوم با یکدیگر مرتبط می‌کند و از این طریق سیاست‌های HA را پیاده‌سازی می‌کند.

6. بررسی وضعیت Pacemaker و کلاستر

برای بررسی وضعیت دقیق Pacemaker و وضعیت کلاستر، دستور زیر را اجرا کنید:

sudo crm status

این دستور یک نمای کلی از وضعیت کلاستر، گره‌ها و منابع نمایش می‌دهد. در صورتی که وضعیت گره‌ها به درستی نشان داده نشود یا مشکلی پیش آید، می‌توانید از دستور زیر برای مشاهده لاگ‌ها استفاده کنید:

sudo tail -f /var/log/pacemaker.log

جمع‌بندی

در این بخش، تنظیمات اولیه Pacemaker شامل پیکربندی منابع، تنظیمات فیلتر و فعال‌سازی مانیتورینگ مورد بررسی قرار گرفت. با استفاده از ابزار crm، می‌توان به راحتی منابع و گره‌های کلاستر را مدیریت کرده و از عملکرد صحیح آن‌ها اطمینان حاصل کرد. علاوه بر این، مانیتورینگ و پیکربندی سیاست‌های HA از اهمیت ویژه‌ای برخوردار است تا در صورت خرابی گره‌ها، منابع به درستی جابجا شوند و کلاستر از نظر دسترسی بالا (HA) به درستی عمل کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”پیکربندی منابع اصلی کلاستر با استفاده از Pacemaker” subtitle=”توضیحات کامل”]در این بخش، نحوه پیکربندی منابع اصلی کلاستر با استفاده از Pacemaker را بررسی خواهیم کرد. منابع در کلاسترهای HA (High Availability) نقش حیاتی دارند، زیرا این منابع باید در صورت خرابی یک گره به‌طور خودکار به گره‌های دیگر منتقل شوند تا از دسترسی بالا و پایدار به خدمات اطمینان حاصل شود.

در اینجا، پیکربندی چند نوع منبع اصلی مانند IP مجازی، سرویس‌های شبکه و منابع ذخیره‌سازی با استفاده از ابزار crm و pcs شرح داده می‌شود.

1. پیکربندی منبع IP مجازی

یکی از منابع اصلی که در اکثر کلاسترها استفاده می‌شود، IP مجازی است. این IP معمولاً برای دسترسی به سرویس‌های کلاستر مورد استفاده قرار می‌گیرد.

برای اضافه کردن یک منبع IP مجازی به کلاستر، دستور زیر را اجرا کنید:

sudo crm configure primitive VirtualIP ocf:heartbeat:IPaddr2 \
    params ip=<ip_address> cidr_netmask=24 \
    op monitor interval="30s"

در این دستور:

• VirtualIP نام منبع است.
• ocf:heartbeat:IPaddr2 نوع منبع IP است که از پروتکل Heartbeat برای مدیریت IP استفاده می‌کند.
• params ip=<ip_address> cidr_netmask=24 آدرس IP مجازی و ماسک شبکه را تعیین می‌کند.
• op monitor interval="30s" به Pacemaker می‌گوید که هر ۳۰ ثانیه وضعیت این منبع را بررسی کند.

مسیر فایل: این دستور هیچ فایلی را ویرایش نمی‌کند، بلکه مستقیماً در کلاستر اجرا می‌شود.

2. پیکربندی سرویس‌ها

یکی دیگر از منابع مهم کلاستر، سرویس‌هایی است که باید به صورت High Availability (HA) اجرا شوند. برای پیکربندی یک سرویس مانند Apache یا MySQL، از دستور زیر استفاده می‌شود:

برای پیکربندی سرویس Apache به عنوان یک منبع:

sudo crm configure primitive ApacheService ocf:heartbeat:apache \
    op monitor interval="60s" timeout="30s"

در این دستور:

• ApacheService نام منبع است.
• ocf:heartbeat:apache نوع منبع است که مربوط به سرویس Apache می‌شود.
• op monitor interval="60s" timeout="30s" برای بررسی وضعیت سرویس به طور دوره‌ای هر ۶۰ ثانیه و با زمان تایم‌اوت ۳۰ ثانیه استفاده می‌شود.

برای پیکربندی سرویس MySQL:

sudo crm configure primitive MySQLService ocf:heartbeat:mysql \
    op monitor interval="60s" timeout="30s"

مسیر فایل: این پیکربندی‌ها در کلاستر اعمال می‌شوند و به طور خاص نیاز به فایل خاصی ندارند، مگر اینکه بخواهید تنظیمات خاصی را در فایل‌های پیکربندی کلاستر اعمال کنید.

3. پیکربندی منابع ذخیره‌سازی

اگر در کلاستر از منابع ذخیره‌سازی اشتراکی استفاده می‌شود، برای اضافه کردن منابع ذخیره‌سازی مانند فایل سیستم‌ها یا دستگاه‌های iSCSI به کلاستر از دستور زیر استفاده می‌شود.

برای پیکربندی یک دستگاه ذخیره‌سازی iSCSI:

sudo crm configure primitive iSCSI_Storage ocf:heartbeat:iSCSILogicalUnit \
    params target=<iscsi_target_ip> lun=<lun_number> \
    op monitor interval="30s"

در این دستور:

• iSCSI_Storage نام منبع است.
• ocf:heartbeat:iSCSILogicalUnit نوع منبع است که برای مدیریت دستگاه‌های iSCSI استفاده می‌شود.
• params target=<iscsi_target_ip> lun=<lun_number> پارامترهای مرتبط با دستگاه iSCSI را مشخص می‌کند.
• op monitor interval="30s" به Pacemaker دستور می‌دهد که هر ۳۰ ثانیه وضعیت این منبع را بررسی کند.

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

4. پیکربندی منابع فایلی (FS)

برای اضافه کردن یک سیستم فایل (مانند NFS یا GFS) به کلاستر، از دستور زیر استفاده می‌شود:

sudo crm configure primitive GFS_Filesystem ocf:heartbeat:Filesystem \
    params device=<device_path> directory=<mount_point> fstype=<filesystem_type> \
    op monitor interval="60s"

در این دستور:

• GFS_Filesystem نام منبع است.
• ocf:heartbeat:Filesystem نوع منبع است که برای سیستم‌های فایل استفاده می‌شود.
• params device=<device_path> مسیر دستگاه ذخیره‌سازی را مشخص می‌کند.
• directory=<mount_point> دایرکتوری که فایل سیستم در آن مونت می‌شود را مشخص می‌کند.
• fstype=<filesystem_type> نوع فایل سیستم (مانند ext4، gfs2، etc.) را مشخص می‌کند.
• op monitor interval="60s" برای بررسی وضعیت فایل سیستم هر ۶۰ ثانیه استفاده می‌شود.

مسیر فایل: این پیکربندی‌ها به طور مستقیم در کلاستر اعمال می‌شود.

5. اتصال منابع به هم (Colocation و Order)

پس از پیکربندی منابع مختلف، ممکن است نیاز داشته باشید که منابع را به یکدیگر متصل کنید تا در هنگام انتقال منابع، ترتیب و وابستگی‌ها رعایت شوند. این کار با استفاده از دستورات colocation و order انجام می‌شود.

برای مثال، برای اینکه منابع IP و Apache هم‌زمان روی یک گره اجرا شوند، می‌توان از دستور زیر استفاده کرد:

sudo crm configure colocation VirtualIP with ApacheService INFINITY

این دستور به Pacemaker می‌گوید که منبع VirtualIP باید هم‌زمان با ApacheService اجرا شود.

برای تعیین ترتیب اجرای منابع، می‌توان از دستور زیر استفاده کرد:

sudo crm configure order ApacheService before VirtualIP

این دستور به Pacemaker می‌گوید که ابتدا باید سرویس Apache راه‌اندازی شود و سپس IP مجازی فعال شود.

جمع‌بندی

در این بخش، پیکربندی منابع اصلی کلاستر با استفاده از Pacemaker، شامل منابع IP، سرویس‌ها، ذخیره‌سازی و سیستم‌های فایل توضیح داده شد. همچنین، نحوه اتصال منابع به یکدیگر با استفاده از دستورات colocation و order برای اطمینان از اجرای صحیح ترتیب منابع در کلاستر شرح داده شد. این پیکربندی‌ها نقش حیاتی در دستیابی به دسترسی بالا و پایداری سیستم دارند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نصب و پیکربندی ابزار pcs برای مدیریت Pacemaker” subtitle=”توضیحات کامل”]ابزار pcs (Pacemaker/Corosync Configuration System) به‌عنوان یک رابط خط فرمان برای مدیریت کلاسترهای Pacemaker و Corosync استفاده می‌شود. این ابزار امکان پیکربندی، مدیریت و نظارت بر منابع، خدمات و وضعیت کلاستر را فراهم می‌آورد. در این بخش، نحوه نصب و پیکربندی ابزار pcs برای مدیریت کلاستر Pacemaker توضیح داده خواهد شد.

1. نصب pcs بر روی گره‌های کلاستر

برای استفاده از ابزار pcs، ابتدا باید این ابزار را بر روی تمام گره‌های کلاستر نصب کنید. در اینجا نحوه نصب این ابزار بر روی سیستم‌های مبتنی بر RHEL/CentOS و Debian/Ubuntu آورده شده است.

برای سیستم‌های RHEL/CentOS:

1. ابتدا مخازن لازم را به‌روز کنید:

   sudo yum update
   

2. سپس ابزار pcs را با استفاده از دستور زیر نصب کنید:

   sudo yum install pcs
   

3. نصب موفقیت‌آمیز این ابزار را با استفاده از دستور زیر بررسی کنید:

   pcs --version
   

برای سیستم‌های Debian/Ubuntu:

1. ابتدا مخازن را به‌روز کنید:

   sudo apt-get update
   

2. سپس ابزار pcs را نصب کنید:

   sudo apt-get install pcs
   

3. نصب موفقیت‌آمیز این ابزار را با استفاده از دستور زیر بررسی کنید:

   pcs --version
   

مسیر فایل: این نصب هیچ فایل خاصی را تغییر نمی‌دهد و فقط ابزار pcs را در سیستم نصب می‌کند.

2. فعال‌سازی و پیکربندی سرویس‌های pcs

پس از نصب، باید سرویس‌های pcs و corosync را فعال کنید تا از ابزار pcs برای مدیریت کلاستر استفاده کنید. ابتدا باید سرویس‌های pacemaker و corosync را به صورت خودکار راه‌اندازی کنید.

برای فعال‌سازی و شروع pcs بر روی هر گره، دستورات زیر را اجرا کنید:

1. فعال‌سازی و راه‌اندازی سرویس‌های pcs:

   sudo systemctl enable pcsd
   sudo systemctl start pcsd
   

2. سپس باید رمز عبور مدیریتی برای pcs را تنظیم کنید. برای این کار از دستور زیر استفاده کنید:

   sudo passwd hacluster
   

   در اینجا، رمز عبور برای کاربر hacluster تنظیم می‌شود که دسترسی مدیریتی به Pacemaker و Corosync را فراهم می‌کند.

3. تنظیم ارتباطات بین گره‌های کلاستر با pcs

برای استفاده از ابزار pcs و راه‌اندازی ارتباط بین گره‌ها، باید از دستور زیر برای تنظیم اعتبارنامه‌ها استفاده کنید:

sudo pcs cluster auth <node1> <node2> -u hacluster -p <password>

در این دستور:

• <node1> و <node2> نام گره‌های کلاستر هستند.
• -u hacluster نام کاربری مدیریتی است که برای Pacemaker و Corosync استفاده می‌شود.
• -p <password> رمز عبور مدیریتی است که قبلاً تنظیم کرده‌اید.

4. راه‌اندازی کلاستر با استفاده از pcs

پس از تنظیم اعتبارنامه‌ها، می‌توانید کلاستر را با استفاده از دستور زیر راه‌اندازی کنید:

sudo pcs cluster setup --name <cluster_name> <node1> <node2>

در این دستور:

• <cluster_name> نام کلاستر است.
• <node1> و <node2> گره‌های کلاستر هستند.

پس از راه‌اندازی کلاستر، باید سرویس‌های کلاستر را شروع کنید:

sudo pcs cluster start --all

5. بررسی وضعیت کلاستر با pcs

برای بررسی وضعیت کلاستر، از دستور زیر استفاده کنید:

sudo pcs status

این دستور اطلاعاتی مانند وضعیت گره‌ها، منابع و سرویس‌ها را به شما نمایش می‌دهد.

6. پیکربندی منابع کلاستر با استفاده از pcs

پس از نصب و راه‌اندازی کلاستر با استفاده از pcs، می‌توانید منابع مختلف را به کلاستر اضافه کنید. برای مثال، برای اضافه کردن یک منبع IP مجازی به کلاستر از دستور زیر استفاده می‌شود:

sudo pcs resource create VirtualIP ocf:heartbeat:IPaddr2 \
    ip=<ip_address> cidr_netmask=24 op monitor interval="30s"

در این دستور:

• VirtualIP نام منبع است.
• ocf:heartbeat:IPaddr2 نوع منبع است.
• ip=<ip_address> آدرس IP مجازی را مشخص می‌کند.
• op monitor interval="30s" زمان بررسی وضعیت این منبع را تعیین می‌کند.

جمع‌بندی

در این بخش، نحوه نصب و پیکربندی ابزار pcs برای مدیریت کلاسترهای Pacemaker توضیح داده شد. ابزار pcs برای پیکربندی و نظارت بر کلاسترهای HA بسیار مفید است و از آن می‌توان برای ایجاد، مدیریت و نظارت بر منابع مختلف در کلاسترهای Pacemaker استفاده کرد. نصب و راه‌اندازی این ابزار روی تمام گره‌ها، فعال‌سازی سرویس‌ها و تنظیم ارتباطات میان گره‌ها گام‌های اساسی در استفاده از pcs هستند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 3. پیکربندی اجزای Pacemaker”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”CRM (Cluster Resource Manager): تعریف منابع، گروه‌ها و اولویت‌های منابع” subtitle=”توضیحات کامل”]در کلاستر Pacemaker، Cluster Resource Manager (CRM) مسئول مدیریت منابع مختلف کلاستر و ارائه خدمات به گره‌های کلاستر است. این اجزا شامل منابع فیزیکی و مجازی هستند که باید مدیریت شوند تا در صورت خرابی یک گره یا مشکل در دسترسی به منابع، این منابع به گره‌های دیگر منتقل شوند. این بخش به بررسی CRM، نحوه تعریف منابع، گروه‌ها و اولویت‌های منابع پرداخته می‌شود.

1. منابع (Resources) در Pacemaker

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

• منابع شبکه (IPهای مجازی)
• منابع ذخیره‌سازی (مانند NFS یا دستگاه‌های SAN)
• سرویس‌ها (مانند Apache یا MySQL)

برای ایجاد یک منبع جدید در کلاستر با استفاده از Pacemaker، از دستور زیر استفاده می‌کنیم:

1.1. ایجاد منبع IP مجازی

فرض کنید می‌خواهیم یک IP مجازی به کلاستر اضافه کنیم. برای این کار از دستور زیر استفاده می‌شود:

sudo pcs resource create VirtualIP ocf:heartbeat:IPaddr2 \
    ip=192.168.1.100 cidr_netmask=24 op monitor interval="30s"

در این دستور:

• VirtualIP نام منبع است.
• ocf:heartbeat:IPaddr2 نوع منبع را نشان می‌دهد که در اینجا یک IP مجازی است.
• ip=192.168.1.100 آدرس IP مجازی را مشخص می‌کند.
• cidr_netmask=24 ماسک شبکه را تعیین می‌کند.
• op monitor interval="30s" مشخص می‌کند که وضعیت این منبع هر 30 ثانیه بررسی شود.

1.2. ایجاد منبع برای سرویس Apache

برای افزودن یک سرویس مانند Apache به کلاستر، می‌توانیم از دستور زیر استفاده کنیم:

sudo pcs resource create ApacheService apache configfile="/etc/httpd/conf/httpd.conf" op monitor interval="10s"

در این دستور:

• ApacheService نام منبع است.
• apache نوع منبع است که به سرویس Apache اشاره دارد.
• configfile="/etc/httpd/conf/httpd.conf" مسیر فایل پیکربندی Apache را مشخص می‌کند.
• op monitor interval="10s" وضعیت این سرویس را هر 10 ثانیه بررسی می‌کند.

2. گروه‌ها (Groups) در Pacemaker

در Pacemaker، می‌توانید منابع مختلف را در قالب گروه‌ها سازمان‌دهی کنید تا مدیریت آنها ساده‌تر شود. گروه‌ها به شما این امکان را می‌دهند که مجموعه‌ای از منابع را به‌طور همزمان مدیریت کنید.

برای ایجاد یک گروه که شامل چندین منبع باشد، از دستور زیر استفاده می‌کنیم:

sudo pcs resource group add WebGroup VirtualIP ApacheService

در این دستور:

• WebGroup نام گروه است.
• VirtualIP و ApacheService منابعی هستند که در این گروه قرار دارند.

3. اولویت‌ها و ترتیب منابع (Resource Constraints)

در Pacemaker، می‌توان منابع را به‌گونه‌ای پیکربندی کرد که در صورت خرابی یک گره، منابع به گره دیگری منتقل شوند. این تنظیمات با استفاده از Constraints یا محدودیت‌ها انجام می‌شود.

3.1. اولویت‌ها (Resource Priorities)

برای تعیین اولویت منابع و تخصیص منابع به گره‌های خاص، می‌توان از Resource Constraints استفاده کرد. به‌عنوان مثال، می‌توان مشخص کرد که یک منبع باید اولویت بالاتری داشته باشد و باید روی گره خاصی اجرا شود.

برای تعریف اولویت در یک کلاستر، می‌توان از دستور زیر استفاده کرد:

sudo pcs constraint location ApacheService prefers node2=INFINITY

در این دستور:

• ApacheService نام منبع است.
• prefers نشان می‌دهد که ترجیح داده می‌شود این منبع روی گره node2 اجرا شود.
• INFINITY به معنای بالاترین اولویت است.

4. بررسی وضعیت منابع و گروه‌ها

برای مشاهده وضعیت تمامی منابع و گروه‌ها در کلاستر، می‌توان از دستور زیر استفاده کرد:

sudo pcs status resources

این دستور اطلاعات دقیقی درباره وضعیت منابع و گروه‌ها را نمایش می‌دهد، از جمله گره‌ای که منابع در آن در حال اجرا هستند.

جمع‌بندی

در این بخش نحوه پیکربندی اجزای مختلف Pacemaker توضیح داده شد. این اجزا شامل منابع، گروه‌ها و اولویت‌ها هستند که به مدیران کلاستر این امکان را می‌دهند تا منابع را به‌طور مؤثر مدیریت کرده و در صورت نیاز به گره‌های مختلف انتقال دهند. ایجاد منابع مختلف مانند IP مجازی و سرویس‌ها، تنظیم گروه‌ها برای مدیریت منابع و تنظیم اولویت‌ها برای تخصیص منابع به گره‌ها، از جمله اقدامات مهم در مدیریت کلاستر با استفاده از Pacemaker هستند.

 [/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”CIB (Cluster Information Base): تنظیمات مربوط به اطلاعات کلاستر و ذخیره‌سازی آن” subtitle=”توضیحات کامل”]CIB (Cluster Information Base) در Pacemaker به عنوان پایگاه داده‌ای برای ذخیره اطلاعات کلاستر عمل می‌کند. این پایگاه داده شامل تمام تنظیمات و وضعیت منابع، گره‌ها، و تنظیمات مربوط به CRM (مدیر منابع کلاستر) است. CIB اطلاعاتی مانند منابع تعریف‌شده، گروه‌ها، وابستگی‌ها، و قوانین اولویت را ذخیره کرده و آن را برای مدیران کلاستر در دسترس قرار می‌دهد. این پایگاه داده به‌طور مستمر به‌روز می‌شود و در صورتی که تغییراتی در کلاستر صورت گیرد، اطلاعات جدید در آن ذخیره می‌شود.

1. ساختار CIB

CIB در واقع یک فایل XML است که تنظیمات و وضعیت‌های کلاستر را ذخیره می‌کند. اطلاعاتی که در CIB ذخیره می‌شوند شامل موارد زیر هستند:

• تعریف منابع: منابعی مانند IP مجازی، سرویس‌ها، دستگاه‌های ذخیره‌سازی، و غیره.
• گروه‌ها: منابعی که به‌صورت گروهی مدیریت می‌شوند.
• محدودیت‌ها (Constraints): قوانینی که نحوه توزیع منابع بین گره‌های کلاستر را تعیین می‌کنند.
• وابستگی‌ها: نحوه تعامل منابع با یکدیگر.
• وضعیت‌ها: وضعیت فعلی هر منبع و گره در کلاستر.

2. مشاهده و ویرایش CIB

برای مشاهده وضعیت فعلی CIB، می‌توان از دستور زیر استفاده کرد:

sudo pcs status

این دستور وضعیت کلی کلاستر را نمایش می‌دهد و نشان می‌دهد که کدام منابع در حال اجرا هستند، گره‌ها چه وضعیتی دارند و تنظیمات مختلف کلاستر چه هستند.

برای مشاهده فایل CIB به‌صورت XML می‌توان از دستور زیر استفاده کرد:

sudo crm configure show

این دستور نمایی از اطلاعات کلاستر در قالب XML به شما نمایش می‌دهد. این اطلاعات شامل منابع، گروه‌ها، اولویت‌ها و دیگر تنظیمات مربوط به CIB است.

3. ویرایش CIB

برای ویرایش اطلاعات CIB، می‌توان از ابزار crm یا pcs استفاده کرد. تغییرات در CIB معمولاً به‌صورت دستی انجام نمی‌شود، زیرا Pacemaker خود به‌طور خودکار این تغییرات را مدیریت می‌کند. با این حال، در صورتی که بخواهید تغییراتی را انجام دهید، باید از ابزارهای مدیریت مانند pcs استفاده کنید.

برای ایجاد یا ویرایش منابع در CIB از دستور زیر استفاده می‌شود:

sudo pcs resource create MyResource ocf:heartbeat:IPaddr2 ip=192.168.1.100

در این دستور:

• MyResource نام منبع جدید است.
• ocf:heartbeat:IPaddr2 نوع منبع است.
• ip=192.168.1.100 آدرس IP مجازی است که به کلاستر اضافه می‌شود.

همچنین برای حذف یک منبع از CIB می‌توان از دستور زیر استفاده کرد:

sudo pcs resource delete MyResource

این دستور منبع MyResource را از CIB حذف می‌کند.

4. ذخیره‌سازی CIB

CIB به‌طور پیش‌فرض در حافظه نگهداری می‌شود و هر تغییری که در کلاستر اعمال شود، به‌طور خودکار در آن ذخیره می‌شود. علاوه بر این، CIB به‌طور دوره‌ای به فایل پشتیبان ذخیره می‌شود که در صورت بروز مشکلات، می‌توان از آن برای بازیابی تنظیمات استفاده کرد.

برای ذخیره‌سازی اطلاعات CIB در فایل پشتیبان می‌توان از دستور زیر استفاده کرد:

sudo crm configure backup /path/to/backup/file

در این دستور، /path/to/backup/file مسیر فایل پشتیبان است که باید ذخیره شود.

5. پشتیبان‌گیری و بازیابی CIB

برای انجام پشتیبان‌گیری از CIB و بازیابی آن در صورت نیاز، می‌توانید از دستورات زیر استفاده کنید.

5.1. پشتیبان‌گیری از CIB

sudo pcs cluster backup /path/to/backup/

این دستور از CIB یک نسخه پشتیبان می‌گیرد که می‌تواند برای بازیابی استفاده شود.

5.2. بازیابی CIB از پشتیبان

sudo pcs cluster restore /path/to/backup/

این دستور پیکربندی کلاستر را از پشتیبان بازیابی می‌کند و به کلاستر بازمی‌گرداند.

جمع‌بندی

در این بخش، نحوه تنظیم و مدیریت CIB (Cluster Information Base) در Pacemaker توضیح داده شد. CIB به‌عنوان پایگاه داده‌ای برای ذخیره و مدیریت تنظیمات و وضعیت کلاستر عمل می‌کند. این اطلاعات شامل منابع، گروه‌ها، وابستگی‌ها و محدودیت‌ها است که توسط Pacemaker به‌طور مستمر به‌روز می‌شوند. ابزارهایی مانند pcs و crm به شما این امکان را می‌دهند که اطلاعات CIB را مشاهده، ویرایش، ذخیره‌سازی و بازیابی کنید تا در صورت بروز مشکلات، تنظیمات کلاستر به‌سرعت بازگردانده شوند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”STONITH (Shoot The Other Node in The Head): پیکربندی اجزای STONITH برای جلوگیری از خرابی‌های ناشی از گره‌های خراب یا دچار مشکلات” subtitle=”توضیحات کامل”]STONITH (Shoot The Other Node in The Head) یک مکانیسم برای محافظت از کلاستر در برابر خرابی‌های احتمالی ناشی از گره‌های خراب است. در این فرآیند، اگر یک گره دچار مشکلاتی شود که نتواند به‌درستی از منابع استفاده کند یا باعث ایجاد مشکلات در کلاستر شود، مکانیسم STONITH آن گره را به‌طور کامل از کلاستر حذف می‌کند تا از ایجاد مشکلات بیشتر جلوگیری کند.

STONITH به‌طور معمول زمانی استفاده می‌شود که یک گره در وضعیت split-brain قرار گیرد یا به هر دلیلی نتواند با کلاستر ارتباط برقرار کند. در این شرایط، STONITH به‌طور خودکار گره را خاموش یا ریستارت می‌کند تا از خرابی و اختلال در سایر گره‌ها جلوگیری شود.

1. مفهوم و عملکرد STONITH

STONITH از یک مکانیسم فیزیکی یا مجازی برای قطع برق گره خراب استفاده می‌کند. این قطع برق می‌تواند به‌صورت دستی یا به‌طور خودکار توسط Pacemaker انجام شود. این فرآیند به کلاستر اجازه می‌دهد تا بدون تداخل از منابع استفاده کند و گره‌های خراب را به‌طور کامل از کلاستر حذف نماید.

مکانیزم STONITH از طریق پروتکل‌های فیزیکی مانند دستگاه‌های IPMI (Intelligent Platform Management Interface)، Fence devices و دیگر تکنولوژی‌ها برای خاموش کردن گره‌های خراب استفاده می‌کند.

2. تنظیمات و پیکربندی STONITH

برای پیکربندی STONITH در کلاستر، باید یک فنس (Fence Device) را انتخاب کنید که قادر به قطع برق گره‌ها باشد. در اینجا از ابزار pcs برای تنظیمات استفاده خواهیم کرد.

2.1. نصب بسته‌های مورد نیاز

ابتدا باید بسته‌های مورد نیاز برای استفاده از STONITH و Fence Devices را نصب کنید. این بسته‌ها شامل ابزارهای مختلفی هستند که برای مدیریت و پیکربندی فنس‌ها استفاده می‌شوند.

برای نصب بسته‌های مورد نیاز در توزیع‌های مبتنی بر Debian (مانند Ubuntu)، دستور زیر را وارد کنید:

sudo apt-get install fence-agents

در توزیع‌های مبتنی بر RedHat (مانند CentOS یا RHEL)، دستور زیر را وارد کنید:

sudo yum install fence-agents

2.2. پیکربندی فنس (Fence Device)

بعد از نصب بسته‌های مورد نیاز، باید یک فنس مناسب انتخاب و پیکربندی کنید. در این مثال، از فنس IPMI برای خاموش کردن گره‌های خراب استفاده می‌کنیم.

برای پیکربندی فنس در Pacemaker از دستور زیر استفاده می‌شود:

sudo pcs stonith create myfence fence_ipmilan pcmk_host_list="node1 node2" ipaddr="192.168.1.100" login="admin" passwd="password" op monitor interval="60s"

در این دستور:

• myfence نام فنس است.
• fence_ipmilan نوع فنس است که از IPMI برای مدیریت برق استفاده می‌کند.
• pcmk_host_list="node1 node2" لیستی از گره‌ها است که این فنس باید به آن‌ها دسترسی داشته باشد.
• ipaddr="192.168.1.100" آدرس IP دستگاه IPMI است که برای مدیریت برق استفاده می‌شود.
• login="admin" نام کاربری برای ورود به دستگاه IPMI.
• passwd="password" رمز عبور برای ورود به دستگاه IPMI.
• op monitor interval="60s" تنظیمات مربوط به نظارت بر وضعیت فنس به‌طور مرتب است.

2.3. تست و بررسی عملکرد STONITH

بعد از پیکربندی STONITH، باید از عملکرد آن اطمینان حاصل کنیم. برای این منظور، می‌توانیم وضعیت فنس را بررسی کنیم.

برای بررسی وضعیت STONITH می‌توان از دستور زیر استفاده کرد:

sudo pcs status

این دستور وضعیت کلاستر و منابع مختلف آن را نشان می‌دهد، از جمله فنس‌ها و وضعیت عملکرد آن‌ها.

برای اطمینان از عملکرد صحیح STONITH، می‌توان گره‌ای را به‌صورت دستی قطع کرد و بررسی کرد که آیا فنس به‌درستی گره را خاموش می‌کند یا خیر. این کار می‌تواند به‌صورت دستی یا با استفاده از ابزارهای خودکار انجام شود.

2.4. پیکربندی چند فنس برای افزایش قابلیت اطمینان

برای افزایش قابلیت اطمینان، می‌توان چندین فنس را پیکربندی کرد. این به کلاستر کمک می‌کند تا در صورت بروز مشکلی در یک فنس، فنس دیگری به‌طور خودکار عملیات خاموش کردن گره خراب را انجام دهد.

برای پیکربندی چند فنس، می‌توان از دستور زیر استفاده کرد:

sudo pcs stonith create myfence1 fence_ipmilan pcmk_host_list="node1 node2" ipaddr="192.168.1.100" login="admin" passwd="password" op monitor interval="60s"
sudo pcs stonith create myfence2 fence_ipmilan pcmk_host_list="node1 node2" ipaddr="192.168.1.101" login="admin" passwd="password" op monitor interval="60s"

در اینجا از دو فنس مختلف به نام‌های myfence1 و myfence2 استفاده می‌شود که به آدرس‌های مختلف IP متصل هستند و از یکدیگر پشتیبانی می‌کنند.

3. بررسی وضعیت STONITH و مانیتورینگ آن

بعد از پیکربندی STONITH، باید به‌طور مداوم وضعیت آن را مانیتور کرده و از عملکرد صحیح آن اطمینان حاصل کرد.

برای بررسی وضعیت STONITH از دستور زیر استفاده می‌شود:

sudo pcs stonith status

این دستور وضعیت منابع STONITH و فنس‌ها را به شما نمایش می‌دهد. در صورتی که یک گره خراب شود، این دستور نشان خواهد داد که کدام فنس برای قطع برق گره استفاده شده است.

جمع‌بندی

در این بخش، نحوه پیکربندی STONITH برای جلوگیری از خرابی‌های ناشی از گره‌های خراب یا دچار مشکلات توضیح داده شد. STONITH به‌طور خودکار گره‌های خراب را شناسایی کرده و از طریق فنس‌های مختلف آن‌ها را خاموش می‌کند تا از ایجاد اختلال در کلاستر جلوگیری شود. پیکربندی فنس‌ها می‌تواند به‌صورت دستی یا خودکار انجام شود و ابزارهایی مانند pcs به شما امکان مدیریت این فرآیند را می‌دهند. همچنین برای افزایش قابلیت اطمینان، می‌توان از چندین فنس استفاده کرد تا در صورت بروز مشکل در یکی از آن‌ها، فنس دیگری وارد عمل شود.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” private_lesson=”true” title=”تعریف و تنظیم سیاست‌های Failover و Failback برای مدیریت منابع در صورت خرابی” subtitle=”توضیحات کامل”]در سیستم‌های کلاستری مانند Pacemaker، Failover و Failback دو مفهوم حیاتی برای مدیریت منابع در صورت خرابی هستند. این سیاست‌ها کمک می‌کنند تا در شرایطی که یک گره یا منبع در کلاستر دچار خرابی می‌شود، عملیات به‌طور خودکار به گره یا منبع دیگری منتقل شود و از اختلال در عملکرد کلاستر جلوگیری شود. این فرآیندها به‌ویژه در محیط‌های پر بار و مهم که نیاز به دسترسی بدون وقفه دارند، بسیار حیاتی هستند.

1. Failover چیست؟

Failover به فرآیند انتقال خودکار منابع یا خدمات از یک گره خراب به گره سالم در کلاستر گفته می‌شود. زمانی که گره‌ای دچار مشکل می‌شود یا به هر دلیلی از دسترس خارج می‌شود، منابع موجود در آن گره به گره دیگری منتقل می‌شوند تا از قطع خدمات جلوگیری شود. این عمل معمولاً بدون هیچ‌گونه دخالت انسانی انجام می‌شود.

در Pacemaker، Failover معمولاً به‌صورت خودکار مدیریت می‌شود و بر اساس سیاست‌های پیکربندی شده منابع به گره‌های سالم منتقل می‌شوند. Pacemaker این فرآیند را از طریق تنظیمات Resource Constraints و Location Constraints انجام می‌دهد.

2. Failback چیست؟

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

در Pacemaker، Failback معمولاً به‌طور خودکار رخ می‌دهد، اما می‌توان آن را با استفاده از تنظیمات مختلف کنترل کرد. به‌عنوان مثال، ممکن است بخواهید منابع فقط پس از مدت زمان مشخصی به گره اصلی بازگردند یا ممکن است بخواهید این کار دستی انجام شود.

3. تنظیم سیاست‌های Failover و Failback در Pacemaker

برای تنظیم Failover و Failback در Pacemaker از دستور pcs برای پیکربندی Resource Constraints و Location Constraints استفاده می‌شود.

3.1. تنظیمات Failover در Pacemaker

برای تنظیم Failover، ابتدا باید منابع کلاستر را با استفاده از دستور pcs resource تعریف کنید و سپس برای آن‌ها محدودیت‌های مکانی (Location Constraints) ایجاد کنید.

برای مثال، فرض کنید که یک سرویس MySQL روی گره‌های node1 و node2 در کلاستر دارید. اگر node1 دچار خرابی شود، سرویس به‌طور خودکار به node2 منتقل می‌شود.

برای ایجاد یک منبع (مثلاً MySQL) و تنظیم Failover به‌صورت زیر عمل می‌کنیم:

sudo pcs resource create MySQL ocf:heartbeat:mysql op monitor interval=30s
sudo pcs constraint location MySQL prefers node2=INFINITY

در این دستور:

• دستور اول منبع MySQL را ایجاد می‌کند.
• دستور دوم به Pacemaker می‌گوید که ترجیحاً MySQL روی node2 اجرا شود. در صورتی که node2 در دسترس نباشد، این منبع به‌طور خودکار به گره دیگر منتقل می‌شود.

3.2. تنظیمات Failback در Pacemaker

برای تنظیم Failback، باید از ویژگی migration-threshold استفاده کنید. این ویژگی مشخص می‌کند که منابع چطور و چه زمانی به گره اصلی خود بازمی‌گردند.

فرض کنید که بعد از خرابی node1، سرویس MySQL به node2 منتقل شده است. اکنون می‌خواهیم منابع پس از ۲ بار تلاش برای انتقال به گره اصلی (یعنی node1) بازگردند.

برای این کار می‌توان از دستور زیر استفاده کرد:

sudo pcs resource op add MySQL migrate threshold=2

در این دستور:

• migrate مشخص می‌کند که سرویس MySQL چند بار باید به گره اصلی خود بازگردد.
• threshold=2 به این معنی است که سرویس MySQL پس از دو تلاش ناموفق برای انتقال به گره اصلی، مجدداً به node1 بازمی‌گردد.

4. تنظیمات پیشرفته Failover و Failback

در صورتی که نیاز به تنظیمات پیشرفته‌تر برای Failover و Failback دارید، می‌توانید از ویژگی‌های Resource Constraints مانند resource-stickiness و failcount استفاده کنید.

4.1. استفاده از resource-stickiness

ویژگی resource-stickiness باعث می‌شود که منابع بعد از Failover به گره‌ای که به آن منتقل شده‌اند، بچسبند و از آنجا جدا نشوند، حتی اگر گره اصلی دوباره سالم شود. این ویژگی معمولاً برای منابعی که نیاز به حفظ وضعیت دارند، مفید است.

برای تنظیم این ویژگی، می‌توانید از دستور زیر استفاده کنید:

sudo pcs resource meta MySQL resource-stickiness=100

در این دستور:

• resource-stickiness=100 به این معنی است که اگر MySQL به node2 منتقل شود، دیگر از آن گره خارج نخواهد شد، حتی اگر node1 مجدداً سالم شود.

4.2. استفاده از failcount

ویژگی failcount مشخص می‌کند که هر منبع چند بار باید در شرایط خرابی تلاش کند تا از گره خارج شود.

برای تنظیم این ویژگی، می‌توانید از دستور زیر استفاده کنید:

sudo pcs resource op add MySQL monitor interval=30s timeout=20s on-fail=restart failcount=3

در این دستور:

• failcount=3 به این معنی است که اگر سرویس MySQL سه بار به‌طور متوالی دچار مشکل شود، از گره خارج می‌شود و به گره دیگری منتقل می‌شود.

جمع‌بندی

در این بخش، نحوه تنظیم سیاست‌های Failover و Failback برای مدیریت منابع در صورت خرابی بررسی شد. Failover به‌طور خودکار منابع را به گره‌های سالم منتقل می‌کند و Failback پس از برطرف شدن خرابی، منابع را به گره اصلی باز می‌گرداند. استفاده از ویژگی‌هایی مانند resource-stickiness و failcount به شما کمک می‌کند تا رفتار منابع را در شرایط مختلف کنترل کنید. تنظیمات و سیاست‌های مختلف در Pacemaker به شما این امکان را می‌دهند تا از عملکرد پایدار و بدون وقفه کلاستر اطمینان حاصل کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 4. مدیریت منابع در کلاستر با استفاده از Pacemaker”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”پیکربندی منابع مختلف (مانند IP address، فایل سیستم‌ها، و سرویس‌ها) در Pacemaker” subtitle=”توضیحات کامل”]در کلاسترهای Pacemaker، می‌توان منابع مختلفی مانند IP address، فایل سیستم‌ها و سرویس‌ها را به‌طور خودکار مدیریت کرد. این منابع در زمان بروز خرابی یا نیاز به انتقال خودکار می‌توانند به گره‌های سالم منتقل شوند. در این بخش، نحوه پیکربندی این منابع در Pacemaker و استفاده از ابزارهای مختلف برای مدیریت آن‌ها توضیح داده می‌شود.

1. پیکربندی IP Address در Pacemaker

برای پیکربندی یک IP address در Pacemaker، از منبع IPaddr2 استفاده می‌شود. این منبع برای مدیریت IP address‌ها در کلاستر به‌کار می‌رود تا در صورت خرابی گره، آدرس IP به گره دیگری منتقل شود.

1.1. ایجاد و پیکربندی IP address

برای ایجاد یک آدرس IP مجازی در کلاستر، می‌توان از دستور زیر استفاده کرد:

sudo pcs resource create VirtualIP IPaddr2 ip=192.168.1.100 cidr_netmask=24 op monitor interval=30s

در این دستور:

• VirtualIP نام منبع است.
• ip=192.168.1.100 آدرس IP مجازی است که باید در کلاستر استفاده شود.
• cidr_netmask=24 زیرشبکه مرتبط با آدرس IP را مشخص می‌کند.
• op monitor interval=30s به Pacemaker می‌گوید که هر ۳۰ ثانیه وضعیت این منبع را بررسی کند.

1.2. مسیر فایل‌ها

این پیکربندی‌ها به‌طور خودکار در CIB (Cluster Information Base) ذخیره می‌شوند. فایل CIB در مسیر /var/lib/pacemaker/cib/cib.xml قرار دارد و تنظیمات منابع در آن ذخیره می‌شود.

2. پیکربندی فایل سیستم‌ها در Pacemaker

Pacemaker به شما این امکان را می‌دهد که فایل سیستم‌ها را نیز به‌طور خودکار مدیریت کنید. این کار برای ایجاد HA (High Availability) در فایل سیستم‌ها انجام می‌شود. برای این منظور، می‌توان از منابع Filesystem استفاده کرد.

2.1. ایجاد و پیکربندی فایل سیستم

فرض کنید می‌خواهیم یک فایل سیستم NFS را روی یک دایرکتوری خاص در کلاستر به‌صورت High Availability پیکربندی کنیم. دستور زیر این کار را انجام می‌دهد:

sudo pcs resource create NFS-Filesystem Filesystem device="/dev/sdb1" directory="/mnt/nfs" fstype="ext4" op monitor interval=20s

در این دستور:

• NFS-Filesystem نام منبع است.
• device="/dev/sdb1" دستگاهی است که فایل سیستم روی آن قرار دارد.
• directory="/mnt/nfs" دایرکتوری mount شده برای این فایل سیستم است.
• fstype="ext4" نوع سیستم فایل است (در اینجا ext4).
• op monitor interval=20s زمان بررسی وضعیت این منبع است که هر ۲۰ ثانیه انجام می‌شود.

2.2. مسیر فایل‌ها

این تنظیمات مانند منابع دیگر در CIB ذخیره می‌شود. فایل CIB در مسیر /var/lib/pacemaker/cib/cib.xml قرار دارد.

3. پیکربندی سرویس‌ها در Pacemaker

برای پیکربندی سرویس‌ها در Pacemaker، از منابع OCF یا Systemd برای مدیریت سرویس‌ها استفاده می‌شود. این سرویس‌ها می‌توانند شامل سرویس‌های مختلفی مانند Apache, MySQL یا هر سرویس دیگری باشند که باید در کلاستر به‌طور خودکار مدیریت شوند.

3.1. ایجاد و پیکربندی سرویس

فرض کنید می‌خواهیم سرویس Apache را در کلاستر به‌طور HA مدیریت کنیم. دستور زیر برای ایجاد و پیکربندی سرویس Apache در Pacemaker به‌کار می‌رود:

sudo pcs resource create Apache ocf:heartbeat:apache configfile="/etc/httpd/conf/httpd.conf" op monitor interval=30s

در این دستور:

• Apache نام منبع است.
• ocf:heartbeat:apache منبع از نوع OCF برای سرویس Apache است.
• configfile="/etc/httpd/conf/httpd.conf" مسیر فایل پیکربندی Apache است.
• op monitor interval=30s زمان بررسی وضعیت این منبع است که هر ۳۰ ثانیه انجام می‌شود.

3.2. مسیر فایل‌ها

تنظیمات منابع سرویس‌ها در همان CIB ذخیره می‌شود. مسیر CIB در /var/lib/pacemaker/cib/cib.xml قرار دارد.

4. استفاده از Constraints برای تنظیم اولویت‌ها و محدودیت‌ها

در برخی مواقع ممکن است بخواهید منابع مختلف را در گره‌های خاصی از کلاستر قرار دهید یا ترتیب اولویت‌ها را برای Failover و Failback مشخص کنید. برای این کار می‌توانید از Constraints استفاده کنید.

4.1. تنظیم اولویت منابع (Location Constraints)

برای تنظیم اولویت منابع در گره‌های خاص، می‌توانید از دستور زیر استفاده کنید:

sudo pcs constraint location VirtualIP prefers node2=INFINITY

در این دستور:

• VirtualIP نام منبع است.
• prefer node2=INFINITY به این معنی است که منبع VirtualIP در node2 اولویت دارد.

4.2. مسیر فایل‌ها

این تنظیمات نیز در CIB ذخیره می‌شود و در فایل /var/lib/pacemaker/cib/cib.xml قرار دارد.

جمع‌بندی

در این بخش نحوه پیکربندی منابع مختلف مانند IP address، فایل سیستم‌ها و سرویس‌ها در Pacemaker بررسی شد. این منابع می‌توانند به‌طور خودکار و به‌صورت High Availability در کلاستر مدیریت شوند. تنظیمات انجام‌شده شامل منابع مختلف از جمله VirtualIP، NFS و Apache با استفاده از دستورات pcs بوده که فایل‌های پیکربندی در CIB ذخیره می‌شوند. استفاده از Constraints برای تنظیم اولویت‌ها و محدودیت‌ها نیز به مدیریت بهتر منابع کمک می‌کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نحوه اضافه کردن و حذف منابع از کلاستر” subtitle=”توضیحات کامل”]در کلاستر Pacemaker، مدیریت منابع شامل اضافه کردن یا حذف منابع از کلاستر است. این کار می‌تواند شامل منابع مختلف مانند IP address، فایل سیستم‌ها، سرویس‌ها و دیگر منابع مورد نیاز برای حفظ قابلیت دسترسی بالا (HA) باشد. در این بخش، نحوه اضافه کردن و حذف منابع از کلاستر با استفاده از ابزار pcs و همچنین توضیحاتی در مورد مسیرهای فایل و پیکربندی‌های لازم آورده شده است.

1. اضافه کردن منابع به کلاستر

برای اضافه کردن یک منبع جدید به کلاستر، از دستور pcs resource create استفاده می‌شود. این دستور به شما این امکان را می‌دهد که منابع مختلف مانند IP address، فایل سیستم‌ها یا سرویس‌ها را به کلاستر اضافه کنید.

1.1. اضافه کردن IP address به کلاستر

برای اضافه کردن یک IP address جدید به کلاستر، از دستور زیر استفاده می‌شود:

sudo pcs resource create VirtualIP IPaddr2 ip=192.168.1.100 cidr_netmask=24 op monitor interval=30s

در این دستور:

• VirtualIP نام منبع است.
• ip=192.168.1.100 آدرس IP مجازی است که باید در کلاستر اضافه شود.
• cidr_netmask=24 مشخص‌کننده زیرشبکه مرتبط با این آدرس IP است.
• op monitor interval=30s به Pacemaker می‌گوید که وضعیت این منبع را هر ۳۰ ثانیه بررسی کند.

1.2. اضافه کردن سرویس به کلاستر

برای اضافه کردن یک سرویس به کلاستر مانند Apache، از دستور زیر استفاده می‌شود:

sudo pcs resource create Apache ocf:heartbeat:apache configfile="/etc/httpd/conf/httpd.conf" op monitor interval=30s

در این دستور:

• Apache نام منبع است.
• ocf:heartbeat:apache نوع منبع است که به‌طور خاص برای سرویس Apache پیکربندی شده است.
• configfile="/etc/httpd/conf/httpd.conf" مسیر فایل پیکربندی Apache است.
• op monitor interval=30s به Pacemaker می‌گوید که وضعیت سرویس Apache را هر ۳۰ ثانیه بررسی کند.

1.3. اضافه کردن فایل سیستم به کلاستر

برای اضافه کردن یک فایل سیستم به کلاستر، می‌توانید دستور زیر را استفاده کنید:

sudo pcs resource create NFS-Filesystem Filesystem device="/dev/sdb1" directory="/mnt/nfs" fstype="ext4" op monitor interval=20s

در این دستور:

• NFS-Filesystem نام منبع است.
• device="/dev/sdb1" دستگاهی است که فایل سیستم روی آن قرار دارد.
• directory="/mnt/nfs" دایرکتوری mount شده برای فایل سیستم است.
• fstype="ext4" نوع سیستم فایل است (در اینجا ext4).
• op monitor interval=20s زمان بررسی وضعیت این منبع است که هر ۲۰ ثانیه انجام می‌شود.

2. حذف منابع از کلاستر

برای حذف یک منبع از کلاستر، از دستور pcs resource delete استفاده می‌شود. این دستور منابعی را که دیگر نیاز به مدیریت ندارند، از کلاستر حذف می‌کند.

2.1. حذف یک IP address از کلاستر

برای حذف یک آدرس IP مجازی از کلاستر، دستور زیر را استفاده می‌کنیم:

sudo pcs resource delete VirtualIP

در این دستور:

• VirtualIP نام منبع است که باید از کلاستر حذف شود.

2.2. حذف سرویس از کلاستر

برای حذف یک سرویس از کلاستر مانند Apache، از دستور زیر استفاده می‌شود:

sudo pcs resource delete Apache

در این دستور:

• Apache نام منبع است که باید از کلاستر حذف شود.

2.3. حذف فایل سیستم از کلاستر

برای حذف یک فایل سیستم از کلاستر، می‌توانید دستور زیر را وارد کنید:

sudo pcs resource delete NFS-Filesystem

در این دستور:

• NFS-Filesystem نام منبع است که باید از کلاستر حذف شود.

3. بررسی وضعیت منابع

بعد از اضافه یا حذف منابع از کلاستر، می‌توانید با استفاده از دستور pcs status وضعیت فعلی منابع کلاستر را بررسی کنید.

برای بررسی وضعیت منابع، دستور زیر را وارد کنید:

sudo pcs status

این دستور وضعیت تمامی منابع کلاستر را نمایش می‌دهد.

مسیر فایل‌ها

تمامی پیکربندی‌ها و تنظیمات منابع در فایل CIB ذخیره می‌شوند. مسیر این فایل به شرح زیر است:

/var/lib/pacemaker/cib/cib.xml

این فایل شامل تنظیمات منابع و اطلاعات مربوط به وضعیت و پیکربندی کلاستر است.

جمع‌بندی

در این بخش، نحوه اضافه کردن و حذف منابع از کلاستر Pacemaker توضیح داده شد. برای اضافه کردن منابع مختلف مانند IP address، فایل سیستم‌ها و سرویس‌ها، از دستورات pcs resource create استفاده می‌شود. برای حذف منابع از کلاستر نیز از دستور pcs resource delete استفاده می‌شود. این تغییرات در فایل CIB ذخیره می‌شود و می‌توانید وضعیت منابع را با دستور pcs status بررسی کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تنظیمات مربوط به Resource Constraints برای کنترل نحوه تخصیص منابع” subtitle=”توضیحات کامل”]در کلاستر Pacemaker، Resource Constraints برای کنترل نحوه تخصیص منابع و اطمینان از تخصیص مناسب منابع به گره‌ها استفاده می‌شود. این تنظیمات به مدیر سیستم این امکان را می‌دهند که منابع خاصی را به گره‌های خاص اختصاص دهد یا منابع را بین گره‌ها تقسیم کند تا از عملکرد مطلوب کلاستر اطمینان حاصل شود. در این بخش، نحوه پیکربندی Resource Constraints و انواع مختلف آن توضیح داده می‌شود.

1. تعریف انواع Resource Constraints

در Pacemaker، چندین نوع Resource Constraints وجود دارد که برای تخصیص منابع و تعیین وابستگی‌ها و اولویت‌ها بین منابع استفاده می‌شود. انواع اصلی آن به شرح زیر است:

1. Location Constraints: برای تعیین محل قرارگیری منابع استفاده می‌شود.
2. Colocation Constraints: برای تعیین اینکه دو یا چند منبع باید با هم اجرا شوند، استفاده می‌شود.
3. Order Constraints: برای تعیین ترتیب اجرای منابع استفاده می‌شود.
4. Score Constraints: برای تنظیم اولویت منابع و تأثیر آن‌ها بر دیگر منابع استفاده می‌شود.

2. Location Constraints

Location Constraints به شما این امکان را می‌دهد که یک منبع خاص را به گره خاصی اختصاص دهید. به عبارت دیگر، می‌توان مشخص کرد که یک منبع باید فقط بر روی یک گره خاص اجرا شود.

برای تنظیم یک Location Constraint، دستور زیر استفاده می‌شود:

sudo pcs constraint location VirtualIP prefers node1=INFINITY

در این دستور:

• VirtualIP نام منبع است.
• node1 نام گره است که منبع باید بر روی آن اجرا شود.
• INFINITY به این معنی است که منبع باید با اولویت بالا بر روی این گره اجرا شود.

برای مثال، اگر بخواهید VirtualIP را فقط بر روی node1 اجرا کنید و اگر node1 در دسترس نبود، این منبع بر روی گره دیگری اجرا نشود، از دستور زیر استفاده می‌کنید:

sudo pcs constraint location VirtualIP prefers node1=INFINITY node2=-INFINITY

در این دستور:

• node1=INFINITY به معنای اولویت بالا برای اجرای منبع بر روی node1 است.
• node2=-INFINITY به این معنی است که VirtualIP نباید بر روی node2 اجرا شود.

3. Colocation Constraints

Colocation Constraints به شما این امکان را می‌دهد که دو یا چند منبع را با هم اجرا کنید. این یعنی منابع مختلف باید در کنار هم روی یک گره اجرا شوند یا بر روی گره‌های خاصی قرار گیرند.

برای تنظیم یک Colocation Constraint، از دستور زیر استفاده می‌شود:

sudo pcs constraint colocation add Apache with VirtualIP INFINITY

در این دستور:

• Apache نام منبع سرویس است.
• VirtualIP نام منبع IP است.
• INFINITY به این معنی است که این منابع باید حتماً با هم اجرا شوند.

اگر بخواهید Apache و VirtualIP را با هم در گره node1 اجرا کنید، از دستور زیر استفاده می‌کنید:

sudo pcs constraint colocation add Apache with VirtualIP INFINITY on node1

4. Order Constraints

Order Constraints برای تعیین ترتیب اجرای منابع استفاده می‌شود. این تنظیمات به شما این امکان را می‌دهند که مشخص کنید که یک منبع باید قبل یا بعد از منبع دیگر اجرا شود.

برای تنظیم یک Order Constraint، از دستور زیر استفاده می‌شود:

sudo pcs constraint order VirtualIP then Apache INFINITY

در این دستور:

• VirtualIP باید ابتدا اجرا شود و سپس Apache شروع به اجرا می‌کند.
• INFINITY به معنای اولویت بالا است.

اگر بخواهید ترتیب اجرای منابع را طوری تنظیم کنید که Apache بعد از VirtualIP اجرا شود، می‌توانید از دستور زیر استفاده کنید:

sudo pcs constraint order Apache then VirtualIP INFINITY

5. Score Constraints

Score Constraints به شما این امکان را می‌دهد که اولویت منابع را برای تخصیص به گره‌ها تنظیم کنید. می‌توانید از این نوع Resource Constraint برای کنترل اینکه منابع در کجا و با چه اولویتی اجرا شوند استفاده کنید.

برای تنظیم Score Constraints، از دستور زیر استفاده می‌شود:

sudo pcs constraint score VirtualIP node1 INFINITY

در این دستور:

• VirtualIP نام منبع است.
• node1 گره‌ای است که منبع باید به آن اختصاص داده شود.
• INFINITY به معنای اولویت بالا است.

برای تنظیم یک امتیاز منفی برای منابع در گره خاص، می‌توانید از دستور زیر استفاده کنید:

sudo pcs constraint score VirtualIP node2 -INFINITY

در این دستور:

• -INFINITY به این معنی است که VirtualIP باید از node2 دوری کند و نباید بر روی آن اجرا شود.

6. مشاهده و حذف Resource Constraints

برای مشاهده تمامی Resource Constraints پیکربندی شده در کلاستر، از دستور زیر استفاده کنید:

sudo pcs constraint show

برای حذف یک Resource Constraint، از دستور زیر استفاده می‌شود:

sudo pcs constraint delete <constraint_name>

در این دستور:

• <constraint_name> نام Resource Constraint است که می‌خواهید حذف کنید.

7. مسیر فایل‌ها

تنظیمات مربوط به Resource Constraints در CIB ذخیره می‌شود و مسیر آن به شرح زیر است:

/var/lib/pacemaker/cib/cib.xml

این فایل حاوی تمامی اطلاعات مربوط به پیکربندی منابع و محدودیت‌های مربوط به نحوه تخصیص منابع در کلاستر است.

جمع‌بندی

در این بخش، نحوه تنظیم و پیکربندی Resource Constraints برای کنترل نحوه تخصیص منابع در Pacemaker شرح داده شد. Location Constraints برای اختصاص منابع به گره‌های خاص، Colocation Constraints برای اجرای همزمان منابع، Order Constraints برای تعیین ترتیب اجرای منابع و Score Constraints برای تنظیم اولویت منابع در نظر گرفته شده‌اند. با استفاده از دستورات pcs constraint می‌توانید این محدودیت‌ها را برای مدیریت منابع و عملکرد بهتر کلاستر ایجاد و پیکربندی کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”پیکربندی منابع پیوسته (Resource Stick) برای جلوگیری از جابه‌جایی منابع در زمان خرابی” subtitle=”توضیحات کامل”]در Pacemaker، گاهی اوقات لازم است که منابع خاصی از جابه‌جایی و انتقال خودکار در صورت خرابی گره جلوگیری کنند. این کار با استفاده از ویژگی Resource Stickiness یا همان منابع پیوسته (که به آن Resource Stick نیز گفته می‌شود) انجام می‌شود. وقتی از این ویژگی استفاده می‌کنید، منابع ترجیح می‌دهند تا در گره‌ای که قبلاً روی آن قرار دارند، باقی بمانند و از جابه‌جایی به گره‌های دیگر اجتناب کنند، حتی اگر گره دچار مشکل شود.

این تنظیمات به شما کمک می‌کند تا منابع حساس یا بحرانی را در محل خاص خود نگه دارید و از انتقال آن‌ها در زمان خرابی جلوگیری کنید. در این بخش، نحوه پیکربندی Resource Stick در Pacemaker توضیح داده خواهد شد.

1. تعریف مفهوم Resource Stickiness

Resource Stickiness یک ویژگی است که به منبع می‌گوید که ترجیح می‌دهد در گره‌ای که قبلاً اجرا شده است باقی بماند. به عبارت دیگر، وقتی که یک منبع در گره‌ای قرار دارد، این ویژگی به Pacemaker دستور می‌دهد که در صورت خرابی یا عدم دسترسی به گره، منبع باید تا حد امکان در همان گره باقی بماند و جابه‌جا نشود، حتی اگر گره خراب شود.

به طور کلی، هنگامی که منابع پیوسته (Sticky Resources) پیکربندی می‌شوند، در شرایط خرابی، این منابع به صورت خودکار جابه‌جا نخواهند شد و Pacemaker سعی می‌کند تا منبع را در گره فعلی نگه دارد، مگر اینکه شرایط خاصی ایجاب کند که منبع باید جابه‌جا شود.

2. نحوه پیکربندی Resource Stickiness

برای پیکربندی منابع پیوسته (Sticky Resources)، از دستور pcs resource و تنظیم resource stickiness استفاده می‌شود. به طور پیش‌فرض، منابع در Pacemaker تمایل دارند که در صورت خرابی، جابه‌جا شوند، اما با تنظیم stickiness، می‌توانید رفتار منابع را تغییر دهید.

برای تنظیم Resource Stickiness برای یک منبع خاص، از دستور زیر استفاده می‌شود:

sudo pcs resource op add <resource_name> stickiness=<value>

در این دستور:

• <resource_name> نام منبع مورد نظر است.
• <value> مقدار stickiness است که می‌تواند مقداری عددی باشد. این مقدار نشان می‌دهد که چقدر منبع تمایل دارد در گره خود باقی بماند. هر چه مقدار بیشتر باشد، منابع تمایل بیشتری به باقی ماندن در گره خود دارند.

برای مثال، اگر بخواهید منبع VirtualIP را پیوسته کنید و از جابه‌جایی آن جلوگیری کنید، می‌توانید دستور زیر را وارد کنید:

sudo pcs resource op add VirtualIP stickiness=INFINITY

در اینجا:

• INFINITY به این معنی است که منبع VirtualIP در هر شرایطی ترجیح می‌دهد در گره‌ای که در حال حاضر در آن قرار دارد، باقی بماند و جابه‌جا نشود.

3. مشاهده و حذف Resource Stickiness

برای مشاهده تنظیمات Resource Stickiness که برای منابع مختلف تنظیم شده‌اند، می‌توانید از دستور زیر استفاده کنید:

sudo pcs resource show

این دستور لیست تمامی منابع و تنظیمات آن‌ها را نمایش می‌دهد، از جمله stickiness آن‌ها.

اگر بخواهید Resource Stickiness را برای یک منبع خاص حذف کنید و اجازه دهید که منبع به طور معمول جابه‌جا شود، می‌توانید از دستور زیر استفاده کنید:

sudo pcs resource op remove <resource_name> stickiness

در این دستور:

• <resource_name> نام منبع است که می‌خواهید تنظیمات stickiness آن را حذف کنید.

برای مثال، برای حذف تنظیمات stickiness از منبع VirtualIP، از دستور زیر استفاده می‌کنید:

sudo pcs resource op remove VirtualIP stickiness

4. مشاهده وضعیت منابع پیوسته

برای مشاهده وضعیت دقیق Resource Stickiness و وضعیت منابع در کلاستر، می‌توانید از دستور زیر استفاده کنید:

sudo crm resource status

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

5. مسیر فایل‌ها

تنظیمات مربوط به Resource Stickiness مانند سایر تنظیمات منابع در CIB ذخیره می‌شود. مسیر فایل آن به شرح زیر است:

/var/lib/pacemaker/cib/cib.xml

این فایل حاوی تمامی تنظیمات کلاستر، از جمله تنظیمات Resource Stickiness، می‌باشد.

جمع‌بندی

در این بخش، نحوه پیکربندی Resource Stickiness در Pacemaker برای جلوگیری از جابه‌جایی منابع در زمان خرابی شرح داده شد. این تنظیمات به شما این امکان را می‌دهند که منابع خاصی را به صورت پیوسته در گره‌های خود نگه دارید و از جابه‌جایی آن‌ها جلوگیری کنید. با استفاده از دستور pcs resource op add و تنظیم مقدار stickiness، می‌توانید منابع را پیوسته کنید و با دستور pcs resource op remove تنظیمات پیوستگی را حذف کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”پیاده‌سازی Resource Fencing برای جلوگیری از دسترسی غیرمجاز یا خرابی منابع” subtitle=”توضیحات کامل”]در محیط‌های کلاستر، به ویژه زمانی که از Pacemaker استفاده می‌شود، Resource Fencing یک مکانیسم بسیار مهم است که برای جلوگیری از خرابی‌های شدید یا دسترسی غیرمجاز به منابع کاربرد دارد. این ویژگی به اطمینان از اینکه منابع فقط در گره‌های سالم و معتبر در حال اجرا هستند، کمک می‌کند. زمانی که یک گره به دلیل خرابی یا مشکل شبکه از کلاستر خارج می‌شود، Fencing به طور خودکار دسترسی آن گره به منابع را مسدود می‌کند.

Resource Fencing برای جلوگیری از موقعیت‌هایی که در آن یک گره خراب یا از کلاستر جدا می‌شود اما همچنان سعی در دسترسی به منابع دارد، طراحی شده است. این وضعیت می‌تواند باعث ایجاد شرایط Split-Brain شود که در آن دو گره به طور هم‌زمان به منابع دسترسی دارند و باعث فساد داده یا خرابی‌های بیشتر می‌شود. با پیاده‌سازی Fencing، این مشکل به حداقل می‌رسد.

در این بخش، نحوه پیاده‌سازی Resource Fencing در Pacemaker و ابزارهای مرتبط برای حفاظت از منابع شرح داده می‌شود.

1. مفهوم Resource Fencing

Resource Fencing در حقیقت به مکانیسمی گفته می‌شود که هنگام شناسایی خرابی یا مشکل در یک گره، به طور خودکار دسترسی آن گره به منابع کلاستر را قطع می‌کند. این کار به منظور جلوگیری از خرابی‌های ناشی از Split-Brain یا دسترسی غیرمجاز به منابع انجام می‌شود. Pacemaker برای انجام Fencing از ابزارهایی مانند STONITH (Shoot The Other Node In The Head) استفاده می‌کند.

2. نحوه پیاده‌سازی Resource Fencing با STONITH

STONITH یک ابزار مهم در Pacemaker است که برای پیاده‌سازی Fencing استفاده می‌شود. این ابزار به طور خودکار گره‌های خراب یا جدا شده از کلاستر را فیزیکی خاموش می‌کند تا مانع از دسترسی آن‌ها به منابع شود.

برای پیاده‌سازی STONITH در Pacemaker، ابتدا باید یک دستگاه یا متد مناسب برای خاموش کردن گره‌ها انتخاب کنید. این دستگاه می‌تواند شامل:

• PowerFence
• IPMI
• SSH
• Fence Agent

3. تنظیمات STONITH در Pacemaker

برای استفاده از STONITH و فعال‌سازی Resource Fencing، نیاز به نصب fence-agents دارید که انواع مختلفی از دستگاه‌ها و متدهای خاموش کردن گره‌ها را پشتیبانی می‌کند. پس از نصب fence-agents، باید یک STONITH resource در کلاستر ایجاد کنید.

4. نصب fence-agents

برای نصب fence-agents در گره‌های کلاستر از دستور زیر استفاده کنید:

sudo apt-get install fence-agents

برای سیستم‌های مبتنی بر RHEL/CentOS:

sudo yum install fence-agents

این دستور fence-agents را بر روی گره نصب می‌کند تا از ابزارهای مختلف برای خاموش کردن گره‌های خراب استفاده شود.

5. پیکربندی STONITH در Pacemaker

پس از نصب fence-agents، باید STONITH را در کلاستر تنظیم کنید. برای این کار، از دستور pcs استفاده می‌شود.

برای افزودن یک STONITH resource از دستور زیر استفاده کنید:

sudo pcs stonith create <resource_name> fence_ipmilan pcmk_host_list="<node1>,<node2>" ipaddr=<ip_address> login=<username> passwd=<password> op monitor interval=60s

در این دستور:

• <resource_name> نام منبع STONITH است.
• <node1> و <node2> نام گره‌های کلاستر هستند.
• <ip_address> آدرس IP دستگاه مدیریت از راه دور است.
• <username> و <password> اطلاعات احراز هویت برای دسترسی به دستگاه مدیریت از راه دور هستند.

برای مثال، اگر از IPMI برای خاموش کردن گره‌ها استفاده می‌کنید، دستور به صورت زیر خواهد بود:

sudo pcs stonith create my_fence_device fence_ipmilan pcmk_host_list="node1,node2" ipaddr=192.168.1.100 login=admin passwd=secret op monitor interval=60s

6. تست عملکرد STONITH

پس از پیکربندی STONITH، لازم است که عملکرد آن را تست کنید. برای این کار، می‌توانید یک گره را به صورت دستی خراب کرده و بررسی کنید که آیا STONITH به درستی عمل می‌کند یا خیر.

برای خاموش کردن گره از طریق STONITH، از دستور زیر استفاده کنید:

sudo pcs stonith fence <node_name>

در این دستور:

• <node_name> نام گره‌ای است که می‌خواهید آن را خاموش کنید.

برای مثال:

sudo pcs stonith fence node1

این دستور گره node1 را به صورت خودکار خاموش می‌کند تا از دسترسی غیرمجاز به منابع جلوگیری کند.

7. مشاهده وضعیت STONITH

برای مشاهده وضعیت STONITH و اینکه آیا به درستی کار می‌کند یا خیر، می‌توانید از دستور زیر استفاده کنید:

sudo pcs status

این دستور وضعیت کلاستر و منابع را نشان می‌دهد و نشان می‌دهد که آیا STONITH به درستی پیکربندی شده و در حال کار است یا خیر.

8. مسیر فایل‌ها

تنظیمات مربوط به STONITH و Resource Fencing در فایل‌های زیر ذخیره می‌شوند:

/var/lib/pacemaker/cib/cib.xml

این فایل حاوی تنظیمات کلاستر و منابع فنسینگ است.

جمع‌بندی

در این بخش، نحوه پیاده‌سازی Resource Fencing برای جلوگیری از دسترسی غیرمجاز و خرابی منابع در Pacemaker شرح داده شد. با استفاده از ابزار STONITH و fence-agents، می‌توان به طور خودکار گره‌های خراب یا جدا شده از کلاستر را خاموش کرد و از ایجاد شرایط Split-Brain و خرابی منابع جلوگیری کرد. با استفاده از دستورات pcs stonith create و pcs stonith fence می‌توان این ویژگی را پیکربندی و آزمایش کرد.[/cdb_course_lesson][cdb_course_lesson title=”فصل 5. نظارت و عیب‌یابی در Pacemaker و Corosync”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از ابزارهای نظارتی مانند crm status, pcs status برای بررسی وضعیت کلاستر” subtitle=”توضیحات کامل”]برای مدیریت و نظارت بر وضعیت کلاستر در Pacemaker، ابزارهای مختلفی وجود دارند که به مدیران سیستم کمک می‌کنند تا وضعیت منابع، گره‌ها و سایر تنظیمات کلاستر را به راحتی بررسی کنند. دو ابزار پرکاربرد در این زمینه crm status و pcs status هستند. این ابزارها به طور مستقیم اطلاعات مربوط به وضعیت کلاستر، منابع، و گره‌ها را ارائه می‌دهند و به شناسایی مشکلات بالقوه کمک می‌کنند.

در این بخش، نحوه استفاده از این ابزارها برای بررسی وضعیت کلاستر شرح داده خواهد شد.

1. ابزار crm status

crm status یکی از ابزارهای اصلی برای نظارت و بررسی وضعیت کلاستر است. این ابزار به طور خاص برای کاربران Corosync/Pacemaker طراحی شده و اطلاعاتی را درباره وضعیت منابع، گره‌ها و وضعیت کلی کلاستر ارائه می‌دهد.

با استفاده از این دستور می‌توانید وضعیت کنونی کلاستر، گره‌ها و منابع آن را مشاهده کنید.

نحوه استفاده از crm status

برای مشاهده وضعیت کلاستر با استفاده از دستور crm status، کافیست دستور زیر را وارد کنید:

sudo crm status

این دستور اطلاعات کاملی را در مورد وضعیت گره‌ها، منابع، و تنظیمات کلاستر به شما نشان می‌دهد. خروجی آن به طور معمول شامل موارد زیر خواهد بود:

• وضعیت هر گره (مثلاً آنلاین یا آفلاین)
• وضعیت هر منبع (فعال یا غیرفعال)
• اطلاعات مربوط به زمان‌بندی و عملیات مختلف در کلاستر

نمونه‌ای از خروجی crm status:

Stack: corosync
Current DC: node1 (version 2.0.0-3) - partition with quorum
Last updated: Thu Mar  4 10:23:47 2025
Last change: Thu Mar  4 09:59:12 2025 by root via cibadmin on node1

3 nodes configured
2 resources configured

Online: [ node1 node2 ]
Standby: [ node3 ]

Resource Group: group1
  IPaddr:   Started node1
  fs:       Started node2

در این خروجی:

• Stack: نشان‌دهنده نوع پشته‌ی کلاستر (مثلاً corosync)
• DC: نماینده مدیر کلاستر (Node1 در اینجا)
• Online: گره‌های آنلاین (در اینجا node1 و node2)
• Standby: گره‌های در حالت استندبای (در اینجا node3)

2. ابزار pcs status

pcs status نیز یکی دیگر از ابزارهای محبوب برای نظارت بر وضعیت کلاستر است. این ابزار به طور مشابه با crm status اطلاعاتی در مورد وضعیت گره‌ها، منابع و تنظیمات کلی کلاستر ارائه می‌دهد، اما از نظر امکانات و قابلیت‌ها کمی جامع‌تر است.

نحوه استفاده از pcs status

برای مشاهده وضعیت کلاستر با استفاده از pcs status، دستور زیر را وارد کنید:

sudo pcs status

خروجی این دستور نیز شامل اطلاعات مشابهی با crm status است و وضعیت کلی کلاستر، گره‌ها، منابع و اطلاعات مهم دیگر را نشان می‌دهد.

نمونه‌ای از خروجی pcs status:

Cluster Name: mycluster
Last updated: Thu Mar  4 10:24:10 2025
Last change: Thu Mar  4 10:20:22 2025 by root via cibadmin on node1

3 nodes configured
2 resources configured
Online: [ node1 node2 ]
Standby: [ node3 ]

Resource Group: group1
  IPaddr:   Started node1
  fs:       Started node2

Nodes:
  node1: Online
  node2: Online
  node3: Standby

Resources:
  IPaddr:   (ocf::heartbeat:IPaddr2)   Started node1
  fs:       (ocf::heartbeat:Filesystem) Started node2

در این خروجی:

• Cluster Name: نام کلاستر (mycluster)
• Online: گره‌های آنلاین (در اینجا node1 و node2)
• Standby: گره‌هایی که در حالت آماده به کار هستند (node3)
• Resources: منابع موجود در کلاستر و وضعیت آنها

3. مقایسه crm status و pcs status

هر دو ابزار crm status و pcs status وضعیت مشابهی از کلاستر ارائه می‌دهند، با این تفاوت که pcs status اطلاعات بیشتری از جمله وضعیت منابع در سطح گره‌ها و وضعیت کلی کلاستر را ارائه می‌دهد. pcs status در کلاسترهای مدرن Pacemaker محبوب‌تر است زیرا امکانات بیشتری دارد و مدیریت آن ساده‌تر است.

4. مشاهده وضعیت منابع با pcs resource status

برای بررسی وضعیت دقیق‌تر هر منبع در کلاستر، می‌توانید از دستور زیر استفاده کنید:

sudo pcs resource status

این دستور اطلاعات دقیقی از وضعیت منابع مختلف در کلاستر می‌دهد، از جمله این‌که هر منبع در کدام گره در حال اجرا است و آیا فعال یا غیرفعال است.

نمونه‌ای از خروجی دستور pcs resource status:

Resource Group: group1
  IPaddr:   Started node1
  fs:       Started node2

Resource "IPaddr" is running on node1
Resource "fs" is running on node2

5. استفاده از ابزارهای دیگر برای نظارت

برای نظارت دقیق‌تر، می‌توانید از ابزارهای Corosync و Pacemaker برای مشاهده وضعیت گره‌ها و منابع استفاده کنید:

• corosync-cfgtool -s: این دستور برای مشاهده وضعیت اتصال گره‌ها و بررسی مشکلات شبکه کاربرد دارد.
• crm_mon: این ابزار برای نظارت دقیق‌تر و در زمان واقعی بر روی وضعیت کلاستر استفاده می‌شود.

6. مسیر فایل‌ها

اطلاعات مربوط به وضعیت کلاستر در فایل‌های زیر ذخیره می‌شوند:

• crm status: اطلاعات وضعیت کلاستر در /var/lib/pacemaker/cib/cib.xml ذخیره می‌شود.
• pcs status: وضعیت کلی کلاستر در /var/lib/pacemaker/cib/cib.xml ذخیره می‌شود.

جمع‌بندی

در این بخش، نحوه استفاده از ابزارهای crm status و pcs status برای نظارت بر وضعیت کلاستر شرح داده شد. این ابزارها اطلاعات دقیقی در مورد وضعیت گره‌ها، منابع و سایر تنظیمات کلاستر ارائه می‌دهند. همچنین با استفاده از دستور pcs resource status می‌توان وضعیت منابع را به طور خاص مشاهده کرد. این ابزارها برای مدیران سیستم ضروری هستند و به شناسایی مشکلات بالقوه در کلاستر کمک می‌کنند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تجزیه و تحلیل لاگ‌های Corosync و Pacemaker برای شناسایی مشکلات” subtitle=”توضیحات کامل”]برای شناسایی مشکلات و تحلیل وضعیت کلاستر، یکی از مهم‌ترین کارها تجزیه و تحلیل لاگ‌ها (logs) است. Corosync و Pacemaker هرکدام لاگ‌های خود را تولید می‌کنند که اطلاعات ارزشمندی در مورد عملکرد و وضعیت گره‌ها، منابع، و سایر اجزای کلاستر ارائه می‌دهند.

در این بخش، نحوه تجزیه و تحلیل لاگ‌های Corosync و Pacemaker برای شناسایی مشکلات شرح داده خواهد شد. بررسی لاگ‌ها می‌تواند به شناسایی مشکلات در شبکه، تنظیمات و منابع کمک کند و برای رفع مشکلات حیاتی که در کلاستر رخ می‌دهند، ضروری است.

1. لاگ‌های Corosync

Corosync مسئول هماهنگی و ارتباط بین گره‌های کلاستر است. این نرم‌افزار در بسیاری از موارد مشکلات شبکه یا ارتباطی را گزارش می‌کند. لاگ‌های Corosync به طور معمول شامل اطلاعاتی در مورد وضعیت ارتباطات بین گره‌ها، زمان‌بندی پیام‌ها و خطاهای احتمالی در شبکه هستند.

محل ذخیره لاگ‌های Corosync

لاگ‌های Corosync به طور پیش‌فرض در مسیر زیر ذخیره می‌شوند:

/var/log/cluster/corosync.log

با استفاده از دستور cat یا less می‌توانید این فایل‌ها را مشاهده کنید:

sudo less /var/log/cluster/corosync.log

تجزیه و تحلیل لاگ‌های Corosync

برای شناسایی مشکلات در ارتباطات گره‌ها یا مشکلات شبکه، لاگ‌های Corosync را باید به دقت بررسی کنید. به ویژه باید به موارد زیر توجه داشته باشید:

• Lost connectivity: این پیام نشان‌دهنده از دست رفتن ارتباط بین گره‌هاست که می‌تواند ناشی از مشکلات شبکه باشد.
• Quorum issues: اگر یک گره نتواند به تعداد حداقل لازم برای «quorum» برسد، این پیام در لاگ ظاهر خواهد شد.
• Join failed: این پیام نشان‌دهنده شکست در تلاش برای پیوستن یک گره به کلاستر است.

نمونه‌ای از یک پیام خطا در لاگ Corosync:

Mar  5 10:34:02 node1 corosync[1234]:   [QUORUM] Sync to 1,2,3 nodes
Mar  5 10:34:05 node1 corosync[1234]:   [QUORUM] lost quorum on node3
Mar  5 10:34:05 node1 corosync[1234]:   [ERROR] Unable to join cluster. Node failed to reach quorum.

در این مثال، node3 نتوانسته به «quorum» دست یابد و اتصال با آن گره قطع شده است. چنین پیامی ممکن است نشان‌دهنده مشکلات شبکه یا پیکربندی اشتباه در گره‌ها باشد.

2. لاگ‌های Pacemaker

Pacemaker مسئول مدیریت منابع و نحوه توزیع آن‌ها در کلاستر است. لاگ‌های Pacemaker اطلاعاتی در مورد وضعیت منابع، گره‌ها، و تغییرات در وضعیت کلاستر را ارائه می‌دهند.

محل ذخیره لاگ‌های Pacemaker

لاگ‌های Pacemaker معمولاً در مسیر زیر ذخیره می‌شوند:

/var/log/pacemaker/pacemaker.log

با استفاده از دستور زیر می‌توانید این فایل‌ها را مشاهده کنید:

sudo less /var/log/pacemaker/pacemaker.log

تجزیه و تحلیل لاگ‌های Pacemaker

برای تجزیه و تحلیل لاگ‌های Pacemaker و شناسایی مشکلات در منابع یا تغییرات در وضعیت کلاستر، باید به نکات زیر توجه کنید:

• Resource failures: این پیام‌ها زمانی ظاهر می‌شوند که یک منبع نتواند به درستی اجرا شود یا از گره‌ای به گره دیگر منتقل شود.
• Resource recovery: این پیام‌ها نشان‌دهنده تلاش‌های Pacemaker برای بازیابی منابع یا انتقال آن‌ها از یک گره به گره دیگر است.
• Node failures: زمانی که یک گره از کلاستر خارج شود یا در حالت آفلاین قرار گیرد، این پیغام‌ها ظاهر می‌شوند.

نمونه‌ای از یک پیام خطا در لاگ Pacemaker:

Mar 5 10:35:03 node1 pacemaker[5678]:   [ERROR] Resource fs failed on node1, attempting recovery
Mar 5 10:35:06 node1 pacemaker[5678]:   [RECOVERY] Resource fs recovered on node2

در این مثال، Pacemaker تلاش کرده است تا منبع fs را که در گره node1 با مشکل مواجه شده بود، به گره node2 منتقل کند.

3. استفاده از ابزار crm_mon برای نظارت در زمان واقعی

برای بررسی وضعیت کلاستر در زمان واقعی و مشاهده لاگ‌های مربوط به مشکلات در لحظه، می‌توانید از دستور crm_mon استفاده کنید. این ابزار وضعیت فعلی گره‌ها و منابع را به طور مداوم نشان می‌دهد.

sudo crm_mon --one-shot --output-as human

خروجی این دستور اطلاعات دقیقی در مورد وضعیت منابع و گره‌ها به شما می‌دهد و در صورت بروز مشکل، می‌توانید آن را در لاگ‌ها شناسایی کنید.

4. تجزیه و تحلیل مشکلات شبکه و همزمانی

بسیاری از مشکلات در کلاسترهای Pacemaker و Corosync به مشکلات شبکه و همزمانی مرتبط هستند. بررسی دقیق‌تر لاگ‌های Corosync به شناسایی مشکلات ارتباطی بین گره‌ها کمک می‌کند. اگر پیغام‌های خطا در مورد مشکلات شبکه و از دست رفتن ارتباط مشاهده می‌کنید، احتمالاً باید مشکلات شبکه را بررسی کنید.

5. جمع‌آوری و مشاهده لاگ‌ها در کلاسترهای پیچیده

در کلاسترهای پیچیده‌تر، بررسی لاگ‌های هر گره به صورت جداگانه مهم است، زیرا ممکن است مشکلات خاص هر گره در لاگ‌های آن گره مشاهده شود. در این صورت، بهتر است از دستورات journalctl برای مشاهده لاگ‌ها در systemd استفاده کنید:

sudo journalctl -u corosync
sudo journalctl -u pacemaker

جمع‌بندی

تجزیه و تحلیل لاگ‌های Corosync و Pacemaker برای شناسایی مشکلات یکی از ابزارهای اصلی مدیریت کلاستر است. بررسی دقیق این لاگ‌ها می‌تواند به شما کمک کند تا مشکلات در ارتباطات گره‌ها، منابع، و تنظیمات کلاستر را شناسایی کنید. به طور کلی، برای شناسایی مشکلات در کلاسترهای Pacemaker و Corosync، باید به موارد زیر توجه کنید:

• لاگ‌های Corosync برای شناسایی مشکلات شبکه و ارتباطات بین گره‌ها.
• لاگ‌های Pacemaker برای شناسایی مشکلات منابع و بازیابی منابع.
• ابزارهای نظارتی مانند crm_mon برای بررسی وضعیت در زمان واقعی.

با استفاده از این ابزارها و تجزیه و تحلیل دقیق لاگ‌ها، می‌توانید مشکلات را شناسایی و رفع کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”دستورات پایه‌ای برای مدیریت منابع کلاستر” subtitle=”توضیحات کامل”]در مدیریت کلاسترهایی که با Pacemaker و Corosync راه‌اندازی شده‌اند، ابزار pcs یکی از ابزارهای اصلی برای مدیریت و پیکربندی منابع است. این ابزار به شما این امکان را می‌دهد که منابع کلاستر را مشاهده، تنظیم و مدیریت کنید. در این بخش، به توضیح برخی از دستورات پایه‌ای که برای مدیریت منابع کلاستر استفاده می‌شوند، خواهیم پرداخت.

1. دستور pcs resource move

این دستور برای جابه‌جا کردن یک منبع از یک گره به گره‌ای دیگر استفاده می‌شود. زمانی که نیاز دارید یک منبع خاص را از گره‌ای به گره دیگر منتقل کنید (مثلاً به دلیل بار زیاد یا خرابی گره)، این دستور به شما کمک می‌کند.

نحوه استفاده:

pcs resource move <resource_name> <target_node>

• <resource_name>: نام منبع که می‌خواهید جابه‌جا کنید.
• <target_node>: نام گره‌ای که می‌خواهید منبع را به آن منتقل کنید.

مثال:

برای جابه‌جایی منبع با نام MyIP به گره‌ای به نام node2، دستور زیر را وارد کنید:

pcs resource move MyIP node2

2. دستور pcs resource disable

این دستور برای غیرفعال کردن یک منبع به‌طور موقت روی یک گره خاص استفاده می‌شود. زمانی که بخواهید از دسترس خارج کردن یک منبع در گره خاصی را مدیریت کنید، از این دستور استفاده می‌شود.

نحوه استفاده:

pcs resource disable <resource_name> [<node_name>]

• <resource_name>: نام منبعی که می‌خواهید غیرفعال کنید.
• <node_name> (اختیاری): نام گره‌ای که می‌خواهید منبع را در آن غیرفعال کنید. اگر این پارامتر را وارد نکنید، منبع از تمامی گره‌ها غیرفعال می‌شود.

مثال:

برای غیرفعال کردن منبع MyIP در گره node1:

pcs resource disable MyIP node1

اگر بخواهید این منبع را از تمامی گره‌ها غیرفعال کنید:

pcs resource disable MyIP

3. دستور pcs resource enable

این دستور برای فعال‌سازی یک منبع که قبلاً غیرفعال شده است، به کار می‌رود. اگر یک منبع به دلایلی غیرفعال شده باشد، این دستور می‌تواند آن را دوباره به حالت فعال برگرداند.

نحوه استفاده:

pcs resource enable <resource_name> [<node_name>]

• <resource_name>: نام منبعی که می‌خواهید فعال کنید.
• <node_name> (اختیاری): نام گره‌ای که می‌خواهید منبع را در آن فعال کنید. اگر این پارامتر را وارد نکنید، منبع در تمامی گره‌ها فعال می‌شود.

مثال:

برای فعال‌سازی منبع MyIP در گره node1:

pcs resource enable MyIP node1

اگر بخواهید این منبع را در تمامی گره‌ها فعال کنید:

pcs resource enable MyIP

4. مشاهده وضعیت منابع با دستور pcs resource status

این دستور وضعیت کلیه منابع موجود در کلاستر را نمایش می‌دهد. به کمک آن می‌توانید وضعیت فعلی هر منبع، گره‌ای که در آن قرار دارد و وضعیت فعال یا غیرفعال بودن آن را مشاهده کنید.

نحوه استفاده:

pcs resource status

مثال:

با استفاده از دستور فوق، شما می‌توانید وضعیت تمامی منابع کلاستر را بررسی کنید.

5. مشاهده وضعیت منابع یک گره خاص

اگر بخواهید وضعیت منابع را فقط برای یک گره خاص بررسی کنید، می‌توانید از دستور زیر استفاده کنید:

pcs resource status <node_name>

مثال:

برای مشاهده وضعیت منابع در گره node1:

pcs resource status node1

جمع‌بندی

دستورات pcs resource move, pcs resource disable, و pcs resource enable ابزارهای قدرتمندی برای مدیریت منابع کلاستر در Pacemaker هستند. این دستورات به شما امکان می‌دهند تا منابع کلاستر را جابه‌جا کرده، آن‌ها را غیرفعال و دوباره فعال کنید و وضعیت کلی منابع را بررسی کنید. این ابزارها برای مدیریت وضعیت منابع در کلاسترهای با چند گره بسیار مفید و کاربردی هستند و می‌توانند در حل مشکلات و مدیریت منابع کمک زیادی کنند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 6. تنظیمات اضافی برای بهبود عملکرد و اطمینان از دسترسی بالا”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”بررسی و تنظیم پارامترهای مرتبط با شبکه در Corosync برای افزایش کارایی و کاهش تأخیر در ارتباطات گره‌ها” subtitle=”توضیحات کامل”]یکی از اجزای کلیدی در ساختار کلاسترهای Pacemaker و Corosync، تنظیمات شبکه‌ای صحیح است که تأثیر زیادی در عملکرد کلی کلاستر و کاهش تأخیرات ارتباطی بین گره‌ها دارد. در این بخش، به بررسی تنظیمات مختلف مربوط به شبکه در Corosync خواهیم پرداخت و نحوه بهینه‌سازی آن‌ها برای افزایش کارایی و کاهش تأخیر را توضیح خواهیم داد.

1. معرفی پارامترهای شبکه‌ای در Corosync

Corosync به‌عنوان یک پیام‌رسان شبکه‌ای برای ارتباط بین گره‌های کلاستر عمل می‌کند. در اینجا چند پارامتر مهم که می‌توانند بر عملکرد شبکه و تأخیر ارتباطات تأثیر بگذارند، معرفی می‌شود:

• Transport (مدل ارتباطی): این پارامتر تعیین می‌کند که Corosync از چه نوع شبکه‌ای برای ارتباط استفاده کند.
• Interface (رابط شبکه): مشخص می‌کند که Corosync از کدام رابط شبکه برای ارتباط استفاده کند.
• Multicast (پخش چندگانه): این تنظیمات برای ارسال پیام‌ها به چندین گره به صورت همزمان استفاده می‌شود.
• Token Timeout (زمان تأخیر توکن): این پارامتر برای تعیین مدت زمانی است که Corosync قبل از این که گره‌های کلاستر آن را از دست بدهند، منتظر می‌ماند.
• Threads (تعداد نخ‌ها): تعداد نخ‌های پردازشی که Corosync برای مدیریت ارتباطات استفاده می‌کند.

2. تنظیمات شبکه‌ای در فایل پیکربندی Corosync

تمام تنظیمات Corosync در فایل پیکربندی آن به نام corosync.conf ذخیره می‌شود که معمولاً در مسیر /etc/corosync/corosync.conf قرار دارد. برای بهینه‌سازی شبکه، باید این فایل پیکربندی را ویرایش کنیم.

3. تنظیم پارامترهای شبکه در Corosync

در ادامه برخی از پارامترهای مهم که می‌توانند در کاهش تأخیر و افزایش کارایی شبکه مؤثر باشند، آورده شده است.

1. تنظیم پارامتر transport

این پارامتر مشخص می‌کند که از چه نوع پروتکلی برای ارتباط استفاده شود. معمولاً برای کلاسترهایی که در شبکه‌های محلی قرار دارند، UDP بهترین گزینه است. در صورت استفاده از شبکه‌های گسترده، می‌توان از TCP استفاده کرد.

برای تنظیم این پارامتر، به فایل corosync.conf رفته و مقادیر مناسب را وارد کنید:

totem {
    version: 2
    secauth: on
    transport: udp
    ...
}

• transport: udp: برای شبکه‌های محلی.
• transport: tcp: برای شبکه‌های گسترده.

2. تنظیم پارامتر interface

این پارامتر برای تعیین رابط شبکه‌ای که Corosync باید از آن استفاده کند، به‌کار می‌رود. اگر سرور شما دارای چندین کارت شبکه باشد، می‌توانید مشخص کنید که از کدام رابط برای ارتباط استفاده کند.

interface {
    ringnumber: 0
    bindnetaddr: 192.168.1.0   # آدرس شبکه
    mcastaddr: 239.255.1.1      # آدرس پخش چندگانه
    mcastport: 5405             # پورت پخش
}

• bindnetaddr: آدرس شبکه‌ای که از آن برای ارتباطات استفاده می‌شود.
• mcastaddr: آدرس پخش چندگانه برای ارسال پیام به تمامی گره‌ها.
• mcastport: پورت استفاده‌شده برای پخش پیام‌ها.

3. تنظیم token timeout

این پارامتر زمان انتظار Corosync برای دریافت پاسخ از گره‌ها را تنظیم می‌کند. با کاهش مقدار این پارامتر، زمان پاسخ‌دهی سریع‌تر می‌شود، اما این ممکن است منجر به مشکلات پایداری در شرایطی با تأخیر بالا گردد. بنابراین، باید مقدار آن را متناسب با شرایط شبکه تنظیم کرد.

totem {
    token: 3000  # زمان انتظار برای دریافت پاسخ به میلی‌ثانیه
}

• token: 3000: تنظیم مقدار زمان تأخیر توکن به ۳۰۰۰ میلی‌ثانیه (۳ ثانیه).

4. تنظیم threads

تعداد نخ‌های پردازشی که برای مدیریت ارتباطات شبکه‌ای استفاده می‌شوند، می‌تواند تأثیر زیادی در عملکرد سیستم داشته باشد. در شبکه‌های با ترافیک بالا، ممکن است نیاز به تعداد بیشتری نخ داشته باشید.

logging {
    to_syslog: yes
    level: info
}

threads: 2  # تعداد نخ‌ها

• threads: 2: تعداد نخ‌های استفاده‌شده برای پردازش پیام‌های شبکه.

4. اعمال تغییرات و راه‌اندازی دوباره Corosync

پس از اعمال تغییرات در فایل corosync.conf، باید سرویس Corosync را دوباره راه‌اندازی کنید تا تغییرات اعمال شوند.

systemctl restart corosync

5. بررسی وضعیت شبکه

برای بررسی وضعیت Corosync و شبکه، می‌توانید از دستور زیر استفاده کنید تا از صحت عملکرد سرویس‌ها و ارتباطات گره‌ها مطمئن شوید:

corosync-cfgtool -s

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

جمع‌بندی

تنظیمات شبکه‌ای در Corosync برای بهینه‌سازی عملکرد و کاهش تأخیر ارتباطات گره‌ها بسیار حیاتی هستند. با تنظیم پارامترهایی مانند transport, interface, token timeout, و threads می‌توان کارایی کلاستر را به‌طور قابل توجهی بهبود بخشید. این تنظیمات به شما این امکان را می‌دهند که عملکرد بهینه‌تری در شرایط مختلف شبکه بدست آورید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”بررسی نحوه مدیریت منابع با اولویت‌بندی در Pacemaker” subtitle=”توضیحات کامل”]در سیستم‌های کلاستری مانند Pacemaker، مدیریت منابع و تخصیص آن‌ها به گره‌ها، نقش مهمی در عملکرد و پایداری کلاستر ایفا می‌کند. یکی از ویژگی‌های کلیدی برای بهینه‌سازی استفاده از منابع، امکان اولویت‌بندی منابع است. در این بخش، به بررسی نحوه مدیریت منابع با استفاده از اولویت‌بندی در Pacemaker خواهیم پرداخت و به چگونگی تخصیص و تنظیم اولویت‌ها برای منابع مختلف کلاستر خواهیم پرداخت.

1. تعریف اولویت‌بندی منابع در Pacemaker

اولویت‌بندی منابع در Pacemaker به این معنی است که می‌توانید منابع مختلف را به ترتیبی که بیشتر برای شما مهم هستند، مدیریت کنید. این امر به‌ویژه در شرایطی که محدودیت‌های منابع (مثل حافظه یا CPU) وجود دارد، بسیار مفید است.

بیشتر منابع مانند IP address, Disks, Services و غیره می‌توانند دارای اولویت‌های متفاوتی باشند. برای مثال، اگر یک گره به‌طور موقت از منابع کمتری برخوردار است، منابع با اولویت پایین‌تر می‌توانند به راحتی از گره‌ای که دارای اولویت بالاتر است، برداشته شوند.

2. استفاده از Resource Constraints برای اولویت‌بندی

در Pacemaker، برای اولویت‌بندی منابع از ویژگی‌هایی مانند Resource Constraints (محدودیت‌های منابع) استفاده می‌شود. این محدودیت‌ها می‌توانند مشخص کنند که کدام منابع در گره‌های خاصی باید در دسترس باشند و ترتیب تخصیص آن‌ها چگونه باشد.

1. Resource Location Constraints

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

برای مثال، اگر یک سرویس خاص باید همیشه روی گره ۱ اجرا شود، می‌توان از محدودیت location استفاده کرد.

pcs constraint location <resource_name> prefers <node_name> score=<value>

• <resource_name>: نام منبع
• <node_name>: نام گره‌ای که منبع باید در آن قرار گیرد
• score: مقدار نمره‌ای که تعیین می‌کند چقدر ترجیح داده می‌شود که منبع روی گره خاص قرار گیرد (مقدار منفی به معنی کمترین ترجیح است).

مثال:

pcs constraint location MyService prefers node1 score=INFINITY

این دستور به این معنی است که منبع MyService به شدت ترجیح داده می‌شود که روی node1 قرار گیرد.

2. Resource Priority Constraints

اولویت منابع در Pacemaker با استفاده از تنظیمات resource priority نیز قابل پیاده‌سازی است. در واقع، با استفاده از این اولویت‌ها، می‌توانید مشخص کنید که کدام منابع نسبت به دیگر منابع در صورت کمبود منابع تخصیص داده شوند.

اولویت‌ها به صورت معمول از عددی در دامنه 0 تا INFINITY تنظیم می‌شوند. INFINITY بالاترین اولویت را دارد.

برای تنظیم اولویت منابع، می‌توانید از دستور pcs resource استفاده کنید. به این صورت که برای هر منبع، اولویت خاصی را تعیین کنید.

pcs resource create <resource_name> <resource_type> priority=<priority_value> options=<resource_options>

• priority: اولویت منبع
• priority_value: عدد اولویت که می‌تواند از 0 تا INFINITY باشد.

مثال:

pcs resource create MyResource ocf:heartbeat:MyResource priority=INFINITY

این دستور منبع MyResource را با بالاترین اولویت (INFINITY) ایجاد می‌کند.

3. تعیین اولویت بین منابع با استفاده از Order Constraints

در صورت داشتن چندین منبع، ممکن است بخواهید ترتیب اجرا یا تخصیص آن‌ها را مشخص کنید. برای این منظور، می‌توان از Order Constraints استفاده کرد. این محدودیت‌ها می‌توانند تعیین کنند که منابع باید در چه ترتیبی اجرا شوند و در صورت بروز مشکل یا خرابی در یکی از منابع، کدام منابع ابتدا باید متوقف یا راه‌اندازی شوند.

pcs constraint order <resource_name_1> then <resource_name_2> score=<value>

• <resource_name_1>: نام اولین منبع
• <resource_name_2>: نام دومین منبع
• score: نمره اولویت که نشان می‌دهد اولویت بین منابع چگونه باید توزیع شود.

مثال:

pcs constraint order MyService then MyDatabase score=INFINITY

این دستور به این معنی است که MyDatabase پس از MyService باید اجرا شود.

4. پیاده‌سازی اولویت‌بندی در حالت Failover

در زمان خرابی یا failover، می‌توان از اولویت‌ها برای تعیین این که کدام منابع باید روی گره‌های جدید راه‌اندازی شوند، استفاده کرد. اگر گره‌ای به‌طور ناگهانی از دست برود، با استفاده از Failover Constraints، منابع با اولویت بالاتر به‌طور خودکار به گره‌های دیگری منتقل می‌شوند.

در صورتی که بخواهید MyService را تنها زمانی روی node1 اجرا کنید که آن گره سالم باشد، و در غیر این صورت باید روی گره‌های دیگر باشد، می‌توانید از دستور زیر استفاده کنید:

pcs constraint location MyService prefers node1 score=INFINITY
pcs constraint location MyService avoids node2 score=-INFINITY

5. مدیریت منابع با استفاده از pcs resource move و pcs resource disable

برای مدیریت منابع در حال اجرا، می‌توانید از دستورات زیر استفاده کنید:

• pcs resource move: برای جابجایی منابع بین گره‌ها.
• pcs resource disable: برای غیرفعال کردن منابع از گره‌ها.
• pcs resource enable: برای فعال‌سازی مجدد منابع.

به عنوان مثال، برای جابجایی یک منبع به گره مشخصی:

pcs resource move MyResource node2

برای غیرفعال کردن یک منبع:

pcs resource disable MyResource

جمع‌بندی

در Pacemaker، اولویت‌بندی منابع یکی از ویژگی‌های کلیدی برای مدیریت منابع در کلاستر است. با استفاده از Resource Constraints، Order Constraints، و پارامترهای location و priority، می‌توانید منابع را به گونه‌ای تنظیم کنید که در زمان نیاز به طور بهینه تخصیص داده شوند. این تنظیمات به شما کمک می‌کنند تا در صورت بروز مشکلات در یکی از منابع، دیگر منابع با اولویت بالاتر به سرعت در دسترس باشند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”پیکربندی Failover سیاست‌ها برای منابع به صورت دقیق‌تر و خودکار” subtitle=”توضیحات کامل”]یکی از اهداف اصلی کلاسترهای HA (High Availability) مانند Pacemaker این است که اطمینان حاصل کند که منابع همواره در دسترس باشند، حتی در صورت خرابی گره‌ها یا منابع. برای این منظور، Failover سیاست‌ها نقش کلیدی دارند. این سیاست‌ها به‌طور خودکار منابع را در صورت خرابی از گره‌ای به گره دیگر منتقل می‌کنند. در این بخش، به نحوه پیکربندی Failover سیاست‌ها برای منابع به‌طور دقیق‌تر و خودکار پرداخته خواهد شد.

1. تعریف Failover و Failback

Failover فرآیندی است که در آن منابع از گره خراب یا مشکل‌دار به گره سالم منتقل می‌شوند. این عملیات به‌طور خودکار صورت می‌گیرد و منابع را از گرهی که به هر دلیلی در دسترس نیست، به گره‌ای که سالم است، منتقل می‌کند.

Failback به معنای بازگشت منابع از گره‌ای است که پس از خرابی مجدداً به حالت آنلاین درآمده است. در این حالت، منابع به‌طور خودکار از گره سالم به گره‌ای که دوباره در دسترس قرار گرفته، منتقل می‌شوند.

2. استفاده از Resource Constraints برای پیکربندی Failover

برای مدیریت Failover و Failback در Pacemaker، می‌توانید از Resource Constraints استفاده کنید. این محدودیت‌ها به شما اجازه می‌دهند که شرایط لازم برای Failover را تعریف کنید، به‌طوری که منابع در صورت خرابی گره به گره دیگری منتقل شوند.

1. Location Constraints برای Failover

با استفاده از Location Constraints، می‌توانید تعیین کنید که منابع بر روی کدام گره‌ها ترجیح داده شوند و یا از کدام گره‌ها اجتناب کنند. در صورت خرابی گره‌ای که منبع روی آن اجرا شده است، این محدودیت‌ها کمک می‌کنند تا منابع به گره‌های سالم منتقل شوند.

برای مثال، فرض کنید می‌خواهید منبع MyService تنها روی node1 اجرا شود و در صورت خرابی این گره، منبع به node2 منتقل شود:

pcs constraint location MyService prefers node1 score=INFINITY
pcs constraint location MyService requires node2 score=1

• در این مثال، MyService به‌طور پیش‌فرض به node1 ترجیح داده می‌شود، اما در صورت خرابی node1، منبع MyService باید به node2 منتقل شود.

2. Order Constraints برای Failover و Failback

Order Constraints برای تعیین ترتیب اجرای منابع و نحوه انتقال آن‌ها استفاده می‌شود. این محدودیت‌ها می‌توانند تعیین کنند که در صورت خرابی، منابع باید در چه ترتیبی به گره‌های دیگر منتقل شوند.

برای مثال، می‌خواهید منبع MyService به‌طور خودکار پس از فعال شدن MyDatabase بر روی node2 منتقل شود:

pcs constraint order MyDatabase then MyService score=INFINITY

این دستور به این معنی است که MyService تنها پس از اینکه MyDatabase روی node2 فعال شد، راه‌اندازی می‌شود.

3. پیکربندی خودکار Failover با استفاده از Resource Stickiness

یکی از ویژگی‌های جالب Pacemaker، قابلیت Resource Stickiness است. این ویژگی می‌تواند مانع از جابجایی منابع به گره‌های دیگر در صورت خرابی گره‌ها شود، مگر اینکه ضرورتاً منابع به گره‌های دیگر منتقل شوند.

برای جلوگیری از جابجایی منابع به گره‌های دیگر پس از Failover، می‌توانید از دستور زیر استفاده کنید:

pcs resource defaults resource-stickiness=INFINITY

این دستور باعث می‌شود که پس از Failover، منابع تا زمانی که گره مورد نظر سالم است، روی همان گره باقی بمانند.

4. تنظیمات Failback

زمانی که گره‌ای که قبلاً از دست رفته بود، دوباره به حالت آنلاین بازمی‌گردد، Failback باعث می‌شود منابع به گره اصلی خود بازگردند. این تنظیمات می‌توانند به‌صورت خودکار یا دستی انجام شوند.

برای فعال‌سازی Failback، شما می‌توانید از ویژگی migration-threshold برای منابع استفاده کنید. این ویژگی به شما کمک می‌کند تا مشخص کنید که پس از چه تعداد تلاش ناموفق، منابع باید به گره اولیه خود بازگردند.

برای مثال:

pcs resource update MyService migration-threshold=3

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

5. استفاده از STONITH برای جلوگیری از خرابی‌های ناشی از گره‌ها

برای اطمینان از اینکه خرابی‌های گره‌ها به درستی مدیریت شوند و منابع به گره‌های جدید منتقل شوند، STONITH (Shoot The Other Node in The Head) به‌عنوان ابزاری برای جلوگیری از خرابی‌های ناشی از گره‌های خراب استفاده می‌شود. این ابزار از خراب شدن منابع در گره‌های خرابی جلوگیری کرده و اطمینان حاصل می‌کند که منابع به گره‌های سالم منتقل شوند.

در صورتی که گره‌ای خراب شود و نتواند منابع را به‌درستی مدیریت کند، STONITH آن را مجدداً راه‌اندازی می‌کند.

برای پیکربندی STONITH، می‌توانید از دستور زیر استفاده کنید:

pcs stonith create my_stonith_device fence_ipmilan pcmk_host_map=default

6. نظارت و بررسی وضعیت Failover

برای بررسی وضعیت و اطمینان از عملکرد صحیح Failover، می‌توانید از دستورات زیر برای نظارت استفاده کنید:

• crm status: برای نمایش وضعیت کلی کلاستر و منابع.
• pcs status: برای نمایش وضعیت دقیق‌تر منابع در کلاستر.

دستورات:

crm status
pcs status

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

جمع‌بندی

پیکربندی Failover سیاست‌ها در Pacemaker به شما کمک می‌کند تا منابع را در صورت خرابی به‌طور خودکار و بهینه به گره‌های سالم منتقل کنید. با استفاده از Location Constraints، Order Constraints، و Resource Stickiness، می‌توانید نحوه تخصیص منابع و زمان انتقال آن‌ها را به‌دقت مدیریت کنید. همچنین، استفاده از ابزارهایی مانند STONITH و migration-threshold، مدیریت منابع و جلوگیری از خرابی‌های ناشی از گره‌های خراب را تضمین می‌کند.[/cdb_course_lesson][/cdb_course_lessons]

[cdb_course_lessons title=”بخش 4. مدیریت منابع کلاستر و شبیه‌سازی خرابی‌ها”][cdb_course_lesson title=”فصل 1. مدیریت منابع کلاستر”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”معرفی مفهوم منابع کلاستر و نحوه مدیریت آن‌ها” subtitle=”توضیحات کامل”]در سیستم‌های کلاستری، منابع به اجزای فیزیکی یا مجازی گفته می‌شود که به منظور ارائه خدمات پایدار و در دسترس به‌طور مداوم، مدیریت می‌شوند. این منابع ممکن است شامل موارد مختلفی مانند IP address، disks، file systems، services، databases و دیگر اجزای نرم‌افزاری و سخت‌افزاری باشند. مدیریت منابع کلاستر به گونه‌ای است که در صورت خرابی یا نقص در عملکرد گره‌ها، منابع باید به گره‌های دیگر منتقل شوند تا عملکرد کلاستر متوقف نشود و خدمات در دسترس باقی بمانند.

در این بخش به بررسی منابع کلاستر و نحوه مدیریت آن‌ها با استفاده از ابزارهایی مانند Pacemaker پرداخته خواهد شد.

1. انواع منابع کلاستر

در یک کلاستر، منابع به دو دسته اصلی تقسیم می‌شوند:

1. منابع فیزیکی (Physical Resources): این منابع معمولاً شامل تجهیزات سخت‌افزاری مانند دیسک‌ها، پردازنده‌ها و IP address می‌شوند که به‌طور مستقیم بر روی گره‌های فیزیکی نصب شده‌اند.
2. منابع نرم‌افزاری (Virtual Resources): منابع نرم‌افزاری ممکن است شامل خدمات، پایگاه داده‌ها، برنامه‌های کاربردی و پروسه‌ها باشند که می‌توانند به‌طور مجازی و بدون وابستگی به یک گره خاص اجرا شوند.

2. منابع مدیریت‌شده توسط Pacemaker

Pacemaker به‌عنوان یک Cluster Resource Manager (CRM) وظیفه مدیریت و کنترل منابع کلاستر را بر عهده دارد. این ابزار با استفاده از Corosync برای برقراری ارتباط بین گره‌ها، منابع را مدیریت و نظارت می‌کند. در Pacemaker، منابع به‌طور خودکار برای اطمینان از دسترس‌پذیری بالا و صحت عملکرد، جابجا می‌شوند.

3. نحوه تعریف و مدیریت منابع در Pacemaker

برای مدیریت منابع در Pacemaker، باید ابتدا آن‌ها را تعریف کنید. این منابع می‌توانند فیزیکی یا نرم‌افزاری باشند و نیاز به پیکربندی دارند تا در صورت خرابی گره یا هرگونه اختلال، به گره‌های دیگر منتقل شوند.

1. تعریف منابع در Pacemaker

برای تعریف منابع در Pacemaker، می‌توانید از دستور pcs استفاده کنید. به عنوان مثال، برای تعریف یک IP address به‌عنوان منبع در کلاستر:

pcs resource create MyIP ocf:heartbeat:IPaddr2 ip=192.168.1.100 cidr_netmask=24 op monitor interval=30s

در این دستور:

• MyIP: نام منبع.
• ocf:heartbeat:IPaddr2: نوع منبع، در این‌جا یک IP address است.
• ip=192.168.1.100: آدرس IP مربوط به منبع.
• cidr_netmask=24: ماسک شبکه.
• op monitor interval=30s: تنظیمات نظارت بر منبع که در هر 30 ثانیه یکبار منبع را بررسی می‌کند.

2. تعریف منابع برای سرویس‌ها

منابعی که مربوط به سرویس‌ها و برنامه‌های کاربردی هستند، به‌طور مشابه تعریف می‌شوند. برای مثال، برای تعریف یک سرویس Apache:

pcs resource create ApacheService ocf:heartbeat:apache configfile="/etc/httpd/conf/httpd.conf" op monitor interval=60s

در این دستور:

• ApacheService: نام منبع.
• ocf:heartbeat:apache: نوع منبع که به سرویس Apache مربوط است.
• configfile="/etc/httpd/conf/httpd.conf": مسیر فایل پیکربندی.
• op monitor interval=60s: تنظیمات نظارت بر منبع که در هر 60 ثانیه یکبار منبع را بررسی می‌کند.

3. حذف منابع از کلاستر

اگر بخواهید یک منبع را از کلاستر حذف کنید، می‌توانید از دستور pcs resource delete استفاده کنید. برای مثال، برای حذف منبع MyIP:

pcs resource delete MyIP

4. مدیریت و نظارت بر منابع کلاستر

برای نظارت و مدیریت منابع کلاستر از دستورات مختلفی استفاده می‌شود:

• crm status: برای نمایش وضعیت کلی کلاستر و منابع آن.
• pcs status: برای نمایش وضعیت دقیق‌تر منابع در کلاستر.
• pcs resource status: برای نمایش وضعیت منابع به‌طور جداگانه.

دستورات:

crm status
pcs status
pcs resource status

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

5. پیکربندی Failover و Failback منابع

در صورتی که یک منبع به گره‌ای اختصاص داده شده باشد و این گره خراب شود، باید منبع به گره دیگری منتقل شود. برای این کار از Failover استفاده می‌شود. همچنین، با استفاده از Failback می‌توان منابع را به گره‌ای که مجدداً آنلاین شده است، بازگرداند.

برای پیکربندی Failover و Failback، می‌توان از Location Constraints و Order Constraints استفاده کرد.

به عنوان مثال، برای تعریف سیاست‌های Failover و Failback:

pcs constraint location MyService prefers node1 score=INFINITY
pcs constraint location MyService requires node2 score=1
pcs constraint order MyDatabase then MyService score=INFINITY

6. استفاده از Resource Stickiness برای مدیریت منابع

Resource Stickiness ویژگی است که به منابع اجازه می‌دهد تا پس از Failover، در همان گره باقی بمانند و تنها در صورتی جابجا شوند که گره فعلی نتواند منبع را مدیریت کند.

برای تنظیم Resource Stickiness:

pcs resource defaults resource-stickiness=INFINITY

این دستور باعث می‌شود که منابع پس از جابجایی به گره جدید، در همان گره باقی بمانند.

جمع‌بندی

مدیریت منابع در کلاستر با استفاده از Pacemaker و Corosync برای اطمینان از در دسترس بودن منابع در صورت خرابی گره‌ها و منابع بسیار مهم است. منابع می‌توانند شامل آدرس‌های IP، سرویس‌ها و برنامه‌های کاربردی باشند و با استفاده از ابزارهایی مانند pcs می‌توان آن‌ها را تعریف، حذف، و نظارت کرد. پیکربندی Failover و Failback به شما امکان می‌دهد تا منابع را به‌طور خودکار به گره‌های دیگر منتقل کنید و از دسترس‌پذیری بالای کلاستر اطمینان حاصل نمایید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از Pacemaker برای مدیریت انواع مختلف منابع” subtitle=”توضیحات کامل”]Pacemaker به‌عنوان یک Cluster Resource Manager (CRM) قدرتمند، وظیفه مدیریت و نظارت بر منابع مختلف در کلاستر را بر عهده دارد. این منابع می‌توانند شامل موارد مختلفی همچون IP addresses، services، file systems، databases و virtual machines باشند. در این بخش، نحوه استفاده از Pacemaker برای مدیریت انواع مختلف منابع در کلاستر به‌طور جامع و کاربردی توضیح داده خواهد شد.

1. تعریف انواع منابع در Pacemaker

در Pacemaker، منابع می‌توانند به‌صورت مختلفی تعریف شوند و این بستگی به نوع منبع (منبع فیزیکی یا نرم‌افزاری) دارد. منابع می‌توانند از نوع OCF (Open Cluster Framework)، LCM (Lifecycle Management) و یا CRM (Cluster Resource Manager) باشند. در این بخش به نحوه مدیریت انواع مختلف منابع پرداخته خواهد شد.

2. انواع منابع در Pacemaker

در Pacemaker، انواع مختلفی از منابع قابل مدیریت هستند:

1. منابع IP address: برای پیکربندی آدرس IP در کلاستر می‌توان از OCF استفاده کرد.مثال: برای اضافه کردن یک IP address به کلاستر:

   pcs resource create MyIP ocf:heartbeat:IPaddr2 ip=192.168.1.100 cidr_netmask=24 op monitor interval=30s
   

   این دستور باعث می‌شود که آدرس IP 192.168.1.100 به‌عنوان یک منبع در کلاستر مدیریت شود.

2. منابع فایل سیستم‌ها (File Systems): برای مدیریت فایل سیستم‌ها، می‌توان از منابع OCF استفاده کرد که به مدیریت مونت کردن و جداسازی فایل سیستم‌ها کمک می‌کند.مثال: برای اضافه کردن یک فایل سیستم:

   pcs resource create MyFilesystem ocf:heartbeat:Filesystem device="/dev/sdb1" directory="/mnt/data" fstype="ext4" op monitor interval=30s
   

   در این دستور:

   • /dev/sdb1: دستگاه دیسک.
   • /mnt/data: مسیر دایرکتوری مونت.
   • fstype="ext4": نوع سیستم فایل.

   این دستور باعث می‌شود که فایل سیستم از دستگاه /dev/sdb1 در دایرکتوری /mnt/data به‌طور خودکار مدیریت شود.

3. منابع سرویس‌ها (Services): برای مدیریت سرویس‌ها در کلاستر، از منابع OCF استفاده می‌شود که شامل سرویس‌هایی مانند Apache، MySQL، و PostgreSQL است.مثال: برای مدیریت سرویس Apache:

   pcs resource create ApacheService ocf:heartbeat:apache configfile="/etc/httpd/conf/httpd.conf" op monitor interval=60s
   

   در این دستور:

   • configfile="/etc/httpd/conf/httpd.conf": فایل پیکربندی Apache.
   • op monitor interval=60s: زمان‌بندی بررسی وضعیت سرویس.
4. منابع دیتابیس‌ها (Databases): منابع دیتابیس می‌توانند شامل MySQL یا PostgreSQL باشند که برای مدیریت و ارائه خدمات پایدار نیاز به نظارت و مدیریت دارند.مثال: برای اضافه کردن یک دیتابیس MySQL به کلاستر:

   pcs resource create MySQL ocf:heartbeat:mysql config="/etc/mysql/my.cnf" op monitor interval=30s
   

   در این دستور:

   • config="/etc/mysql/my.cnf": فایل پیکربندی MySQL.
   • op monitor interval=30s: تنظیم نظارت بر سرویس MySQL در فواصل زمانی 30 ثانیه.
5. منابع ماشین‌های مجازی (Virtual Machines): یکی دیگر از انواع منابعی که می‌توان در Pacemaker مدیریت کرد، ماشین‌های مجازی (VMs) هستند که می‌توانند به‌صورت کاملاً خودکار در صورت خرابی گره‌ها جابجا شوند.مثال: برای مدیریت یک ماشین مجازی:

   pcs resource create VM1 ocf:heartbeat:VirtualDomain configfile="/etc/libvirt/qemu/vm1.xml" op monitor interval=60s
   

   در این دستور:

   • configfile="/etc/libvirt/qemu/vm1.xml": مسیر فایل پیکربندی ماشین مجازی.
   • op monitor interval=60s: زمان‌بندی نظارت بر وضعیت ماشین مجازی.

3. مدیریت منابع به‌وسیله دستورات مختلف

بعد از تعریف و پیکربندی منابع، می‌توان از دستورات مختلف برای مدیریت و نظارت بر آن‌ها استفاده کرد. برخی از دستورات مهم عبارتند از:

1. crm status: برای مشاهده وضعیت کلی کلاستر و منابع به‌صورت خلاصه.

   crm status
   

2. pcs status: برای مشاهده وضعیت دقیق‌تر منابع و گره‌های کلاستر.

   pcs status
   

3. pcs resource status: برای نمایش وضعیت یک منبع خاص.

   pcs resource status MyIP
   

4. pcs resource move: برای جابجایی یک منبع به گره‌ای دیگر.

   pcs resource move MyIP node2
   

5. pcs resource disable: برای غیرفعال کردن یک منبع در گره مشخص.

   pcs resource disable MyIP
   

6. pcs resource enable: برای فعال کردن یک منبع در گره مشخص.

   pcs resource enable MyIP
   

4. پیکربندی Failover و Failback منابع

در صورت بروز خرابی در یکی از گره‌ها، منابع باید به گره‌ای دیگر منتقل شوند. این کار با استفاده از Failover انجام می‌شود و پس از بازگشت گره خراب، منابع می‌توانند به گره قبلی بازگردند که این فرایند Failback نامیده می‌شود.

برای پیکربندی Failover و Failback می‌توان از دستور pcs constraint برای تعیین اولویت‌ها استفاده کرد.

مثال Failover:

pcs constraint location MyIP prefers node2 score=INFINITY
pcs constraint location MyIP requires node1 score=1

در این دستور:

• Failover: اولویت‌بندی می‌شود که منبع MyIP ابتدا بر روی node2 اجرا شود و اگر این گره در دسترس نباشد، به node1 منتقل شود.

جمع‌بندی

Pacemaker به‌عنوان یک Cluster Resource Manager قدرتمند، به شما این امکان را می‌دهد که منابع مختلف کلاستر را از جمله آدرس‌های IP، سرویس‌ها، فایل سیستم‌ها و ماشین‌های مجازی به‌طور مؤثر مدیریت کنید. مدیریت منابع در کلاستر برای تضمین در دسترس بودن و کاهش خرابی‌ها ضروری است. ابزارهای مختلف مانند pcs resource و crm status برای نظارت و مدیریت این منابع در دسترس هستند. همچنین، با استفاده از پیکربندی Failover و Failback می‌توان منابع را به‌طور خودکار در صورت بروز خرابی به گره‌های دیگر منتقل کرد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تعریف منابع ثابت و منابع قابل انتقال در کلاستر” subtitle=”توضیحات کامل”]در کلاسترهای مبتنی بر Pacemaker و Corosync، منابع به دو دسته منابع ثابت و منابع قابل انتقال تقسیم می‌شوند. هرکدام از این منابع ویژگی‌ها و رفتارهای خاص خود را دارند که باعث می‌شود در سناریوهای مختلف به‌طور متفاوتی مدیریت شوند. در این بخش، به تعریف این دو نوع منبع و تفاوت‌های آن‌ها پرداخته خواهد شد.

1. منابع ثابت (Sticky Resources)

منابع ثابت (یا Sticky Resources) منابعی هستند که پس از تخصیص به یک گره، باید در همان گره باقی بمانند و در صورت بروز خرابی یا نیاز به جابجایی، از گره مقصد به‌طور خودکار جابجا نمی‌شوند، مگر اینکه شرایط خاصی اتفاق بیفتد.

ویژگی‌های منابع ثابت:

• پایبندی به گره: این منابع پس از جابجایی به یک گره، به طور خودکار به گره دیگر منتقل نمی‌شوند.
• پیکربندی: این منابع معمولاً با سیاست‌های Failover و Stickiness پیکربندی می‌شوند.
• زمان جابجایی: منابع ثابت تنها در شرایط خاص مانند خرابی کامل گره یا تغییرات اساسی کلاستر جابجا می‌شوند.

برای پیاده‌سازی منابع ثابت، از ویژگی Resource Stickiness در Pacemaker استفاده می‌شود. به‌این‌ترتیب، پس از تخصیص یک منبع به یک گره، این منبع در گره باقی می‌ماند تا زمانی که به‌طور اجبار مجبور به جابجایی باشد.

مثال: برای پیکربندی یک منبع ثابت (که نباید به‌طور خودکار جابجا شود) از دستور زیر استفاده می‌شود:

pcs resource create MyStickyResource ocf:heartbeat:Filesystem device="/dev/sdb1" directory="/mnt/data" fstype="ext4" op monitor interval=30s
pcs constraint location MyStickyResource prefers node1 score=INFINITY

در این مثال:

• منبع MyStickyResource به گره node1 اختصاص داده شده است و stickiness آن به‌طور INFINITY تعیین شده که به این معنی است که این منبع تا زمانی که گره node1 خراب نشود، به آن گره منتقل خواهد شد.

2. منابع قابل انتقال (Movable Resources)

منابع قابل انتقال (یا Movable Resources) منابعی هستند که می‌توانند به راحتی بین گره‌ها جابجا شوند، بدون اینکه نیاز به پیکربندی خاصی داشته باشند. این منابع معمولاً برای سرویس‌ها، ماشین‌های مجازی یا خدماتی که باید در گره‌های مختلف در دسترس باشند، استفاده می‌شوند.

ویژگی‌های منابع قابل انتقال:

• جابجایی بین گره‌ها: این منابع می‌توانند به‌طور مداوم بین گره‌ها جابجا شوند تا از در دسترس بودن بالاتر و همچنین استفاده بهینه از منابع سخت‌افزاری اطمینان حاصل شود.
• پیکربندی آسان: این منابع به‌راحتی با استفاده از دستورات ساده در کلاستر مدیریت می‌شوند.
• پویایی: این منابع می‌توانند به‌صورت پویا از گره‌ای به گره دیگر منتقل شوند بدون اینکه تأثیر منفی بر عملکرد کلی کلاستر داشته باشند.

مثال: برای پیکربندی یک منبع قابل انتقال، از دستور زیر استفاده می‌شود:

pcs resource create MyMovableResource ocf:heartbeat:IPaddr2 ip=192.168.1.100 cidr_netmask=24 op monitor interval=30s

در این مثال:

• منبع MyMovableResource به‌طور خودکار بین گره‌ها جابجا می‌شود، و آدرس IP 192.168.1.100 به‌عنوان یک منبع قابل انتقال در کلاستر مدیریت می‌شود.

3. تفاوت‌های اصلی بین منابع ثابت و منابع قابل انتقال

ویژگی	منابع ثابت	منابع قابل انتقال
جابجایی بین گره‌ها	به‌طور خودکار جابجا نمی‌شود	به‌طور خودکار بین گره‌ها جابجا می‌شود
چگونگی مدیریت	به‌صورت دستی و با تنظیمات Stickiness مدیریت می‌شود	به‌صورت پویا و خودکار جابجا می‌شود
کاربرد معمول	منابع حساس یا خاص که باید در گره خاصی باقی بمانند	سرویس‌ها، IPها و منابعی که نیاز به در دسترس بودن در گره‌های مختلف دارند
پیکربندی جابجایی	نیاز به پیکربندی‌های خاص برای جلوگیری از جابجایی	پیکربندی‌های کم و خودکار برای جابجایی
استفاده در خرابی	جابجایی تنها در صورت خرابی گره یا نیاز به تغییرات اساسی انجام می‌شود	در هر زمان، برای بهینه‌سازی منابع و جلوگیری از بار اضافی در گره‌ها جابجا می‌شود

4. مثال‌هایی از منابع ثابت و قابل انتقال

1. منبع ثابت:
   • دیسک‌ها و فایل سیستم‌ها که باید به‌طور دائم در یک گره خاص باقی بمانند و تنها در صورت خرابی گره جابجا شوند.
   • سرورهای اختصاصی که خدمات خاصی را برای یک برنامه یا کاربر ارائه می‌دهند.
2. منبع قابل انتقال:
   • آدرس‌های IP مجازی که می‌توانند به‌طور پویا بین گره‌های مختلف جابجا شوند تا در دسترس بودن بالا تضمین شود.
   • سرویس‌های وب یا دیتابیس‌ها که نیاز به مقیاس‌پذیری و قابلیت انتقال به گره‌های مختلف دارند.

جمع‌بندی

در کلاسترهای Pacemaker، منابع به دو دسته ثابت و قابل انتقال تقسیم می‌شوند. منابع ثابت به‌طور معمول در یک گره خاص باقی می‌مانند و تنها در صورت بروز خرابی یا شرایط خاص جابجا می‌شوند، در حالی که منابع قابل انتقال به‌صورت خودکار و پویا بین گره‌ها جابجا می‌شوند تا در دسترس بودن بالا و استفاده بهینه از منابع سخت‌افزاری در کلاستر تضمین شود. شناخت این تفاوت‌ها به مدیریت بهتر منابع و افزایش کارایی کلاستر کمک می‌کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”مدیریت منابع مختلف: IP، فایل‌سیستم‌ها، سرویس‌ها و برنامه‌ها” subtitle=”توضیحات کامل”]در کلاسترهای Pacemaker، مدیریت منابع مختلف نظیر آدرس‌های IP، فایل‌سیستم‌ها، سرویس‌ها و برنامه‌ها از اهمیت بالایی برخوردار است. این منابع معمولاً باید به‌طور دقیق و با تنظیمات خاص مدیریت شوند تا عملکرد بهینه کلاستر و در دسترس بودن بالا تضمین شود. در این بخش به نحوه مدیریت این منابع پرداخته خواهد شد.

1. مدیریت IP در کلاستر

آدرس‌های IP یکی از منابع اساسی در کلاسترهای HA (High Availability) هستند. این آدرس‌ها باید به‌طور خودکار در صورت خرابی یک گره به گره دیگر منتقل شوند تا دسترسی به خدمات تحت شبکه بدون وقفه ادامه یابد.

پیکربندی و مدیریت IP با Pacemaker: برای مدیریت آدرس‌های IP در Pacemaker از منابع IPaddr2 استفاده می‌شود. این منابع به‌طور خودکار آدرس‌های IP را بین گره‌ها جابجا می‌کنند.

دستور پیکربندی IP در Pacemaker:

pcs resource create MyIP ocf:heartbeat:IPaddr2 ip=192.168.1.100 cidr_netmask=24 op monitor interval=30s

در این دستور:

• MyIP نام منبع IP است.
• ocf:heartbeat:IPaddr2 نشان‌دهنده نوع منبع است که در اینجا آدرس IP است.
• ip=192.168.1.100 آدرس IP است که باید به گره‌ها اختصاص یابد.
• cidr_netmask=24 مشخص می‌کند که چه تعداد بیت برای آدرس‌دهی شبکه استفاده می‌شود.

در این سناریو، این آدرس IP به‌طور خودکار از گره‌ای به گره دیگر منتقل می‌شود.

2. مدیریت فایل‌سیستم‌ها

فایل‌سیستم‌ها یکی از منابع حیاتی در کلاسترهای HA هستند. این منابع معمولاً برای نگهداری داده‌ها یا برنامه‌ها مورد استفاده قرار می‌گیرند. فایل‌سیستم‌ها باید به‌طور دقیق مدیریت شوند تا در صورت خرابی گره یا نیاز به جابجایی، دسترسی به داده‌ها به‌طور مداوم فراهم شود.

پیکربندی فایل‌سیستم‌ها در Pacemaker: برای مدیریت فایل‌سیستم‌ها، می‌توان از منابع OCF مانند Filesystem استفاده کرد. این منابع اجازه می‌دهند که فایل‌سیستم‌ها در کلاستر مدیریت شده و در صورت نیاز به گره دیگر منتقل شوند.

دستور پیکربندی فایل‌سیستم در Pacemaker:

pcs resource create MyFilesystem ocf:heartbeat:Filesystem device="/dev/sdb1" directory="/mnt/data" fstype="ext4" op monitor interval=30s

در این دستور:

• MyFilesystem نام منبع فایل‌سیستم است.
• ocf:heartbeat:Filesystem نوع منبع است که برای فایل‌سیستم‌ها استفاده می‌شود.
• device=”/dev/sdb1″ دستگاهی است که فایل‌سیستم روی آن قرار دارد.
• directory=”/mnt/data” مسیر دایرکتوری که فایل‌سیستم باید در آن نصب شود.
• fstype=”ext4″ نوع سیستم فایل (در اینجا ext4) است.

این منبع به‌طور خودکار در صورت خرابی گره به گره دیگر منتقل می‌شود.

3. مدیریت سرویس‌ها

سرویس‌ها معمولاً در کلاسترها برای ارائه خدمات خاص مورد استفاده قرار می‌گیرند. در کلاسترهای Pacemaker، سرویس‌ها باید به‌طور خودکار و با دستورات خاص مدیریت شوند تا در صورت خرابی یا نیاز به جابجایی، از در دسترس بودن بالایی برخوردار باشند.

پیکربندی سرویس‌ها در Pacemaker: برای مدیریت سرویس‌ها، معمولاً از منابع OCF استفاده می‌شود. این منابع به‌طور خودکار سرویس‌ها را در گره‌های مختلف مدیریت می‌کنند.

دستور پیکربندی سرویس‌ها در Pacemaker:

pcs resource create MyService ocf:heartbeat:apache configfile="/etc/httpd/httpd.conf" op monitor interval=30s

در این دستور:

• MyService نام منبع سرویس است.
• ocf:heartbeat:apache نوع منبع است که برای سرویس Apache HTTP استفاده می‌شود.
• configfile=”/etc/httpd/httpd.conf” مسیر فایل پیکربندی سرویس است.
• op monitor interval=30s زمان‌بندی نظارت بر سرویس هر ۳۰ ثانیه است.

در این حالت، سرویس Apache به‌طور خودکار بین گره‌ها جابجا می‌شود و از در دسترس بودن سرویس در کلاستر اطمینان حاصل می‌شود.

4. مدیریت برنامه‌ها

برنامه‌ها نیز یکی از منابع حیاتی در کلاسترها هستند که باید به‌طور دقیق مدیریت شوند. در صورتی که برنامه‌ها نیاز به مقیاس‌پذیری یا اجرای همزمان در چند گره داشته باشند، باید منابع آن‌ها به‌طور دقیق پیکربندی شوند تا از خرابی‌ها جلوگیری شود.

پیکربندی برنامه‌ها در Pacemaker: برای مدیریت برنامه‌ها، مانند سرویس‌ها، می‌توان از منابع OCF یا LSB استفاده کرد. این منابع به‌طور خودکار برنامه‌ها را در گره‌های مختلف مدیریت می‌کنند.

دستور پیکربندی برنامه‌ها در Pacemaker:

pcs resource create MyApp ocf:heartbeat:postgresql pgdata="/var/lib/pgsql/data" op monitor interval=30s

در این دستور:

• MyApp نام منبع برنامه است.
• ocf:heartbeat:postgresql نوع منبع است که برای برنامه PostgreSQL استفاده می‌شود.
• pgdata=”/var/lib/pgsql/data” مسیر دایرکتوری داده‌های PostgreSQL است.
• op monitor interval=30s زمان‌بندی نظارت بر برنامه هر ۳۰ ثانیه است.

این منبع به‌طور خودکار در صورت خرابی گره یا نیاز به جابجایی به گره دیگر منتقل می‌شود.

جمع‌بندی

در کلاسترهای Pacemaker، مدیریت منابع مختلف مانند IP‌ها، فایل‌سیستم‌ها، سرویس‌ها و برنامه‌ها بسیار اهمیت دارد. این منابع می‌توانند به‌طور خودکار بین گره‌ها جابجا شوند تا از در دسترس بودن بالا و کارایی سیستم اطمینان حاصل شود. برای مدیریت این منابع از دستورات خاص استفاده می‌شود که می‌توانند به‌طور دقیق و بدون وقفه عملکرد کلاستر را تضمین کنند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”پیکربندی منابع در Pacemaker با استفاده از دستورات crm configure یا pcs resource create” subtitle=”توضیحات کامل”]در Pacemaker، پیکربندی منابع می‌تواند از طریق ابزارهای مختلفی انجام شود. دو ابزار رایج برای این کار crm و pcs هستند که به ترتیب برای CLI‌های قدیمی‌تر و ابزار مدیریت جدیدتر استفاده می‌شوند. هر دو ابزار قابلیت پیکربندی منابع مختلف را فراهم می‌آورند. در این بخش، نحوه پیکربندی منابع با استفاده از دستورات crm configure و pcs resource create شرح داده خواهد شد.

1. پیکربندی منابع با استفاده از دستور crm configure

دستور crm configure به شما این امکان را می‌دهد که منابع مختلف را در Pacemaker از طریق خط فرمان (CLI) پیکربندی کنید.

برای پیکربندی یک منبع در Pacemaker، ابتدا باید وارد حالت crm configure شوید و سپس منابع مورد نظر را با استفاده از دستورات مربوطه ایجاد کنید.

مراحل پیکربندی منابع با crm configure:

1. وارد محیط crm configure شوید:

   crm configure
   

2. پس از ورود به محیط crm configure، می‌توانید یک منبع را به کلاستر اضافه کنید. به عنوان مثال، برای ایجاد یک منبع IP:

   primitive MyIP ocf:heartbeat:IPaddr2 ip=192.168.1.100 cidr_netmask=24
   

3. برای تعریف یک منبع فایل‌سیستم، از دستور زیر استفاده می‌کنیم:

   primitive MyFilesystem ocf:heartbeat:Filesystem device="/dev/sdb1" directory="/mnt/data" fstype="ext4"
   

4. برای ذخیره و اعمال تغییرات، دستور commit را وارد کنید:

   commit
   

5. برای خروج از محیط crm configure، دستور exit را وارد کنید:

   exit
   

2. پیکربندی منابع با استفاده از دستور pcs resource create

ابزار pcs یک ابزار ساده‌تر و پیشرفته‌تر برای پیکربندی و مدیریت منابع در Pacemaker است. این ابزار با استفاده از دستورات خاص به شما این امکان را می‌دهد که منابع مختلف را به‌طور دقیق و سریع پیکربندی کنید.

مراحل پیکربندی منابع با pcs resource create:

1. برای ایجاد یک منبع IP با استفاده از دستور pcs resource create، از دستور زیر استفاده کنید:

   pcs resource create MyIP ocf:heartbeat:IPaddr2 ip=192.168.1.100 cidr_netmask=24 op monitor interval=30s
   

   در این دستور:

   • MyIP نام منبع IP است.
   • ocf:heartbeat:IPaddr2 نوع منبع است که در اینجا آدرس IP است.
   • ip=192.168.1.100 آدرس IP است که باید به گره‌ها اختصاص یابد.
   • cidr_netmask=24 مشخص می‌کند که چه تعداد بیت برای آدرس‌دهی شبکه استفاده می‌شود.
   • op monitor interval=30s زمان‌بندی نظارت بر این منبع را هر ۳۰ ثانیه مشخص می‌کند.
2. برای ایجاد یک منبع فایل‌سیستم با استفاده از دستور pcs resource create، از دستور زیر استفاده کنید:

   pcs resource create MyFilesystem ocf:heartbeat:Filesystem device="/dev/sdb1" directory="/mnt/data" fstype="ext4" op monitor interval=30s
   

3. برای ایجاد یک منبع سرویس مانند Apache:

   pcs resource create MyService ocf:heartbeat:apache configfile="/etc/httpd/httpd.conf" op monitor interval=30s
   

4. برای مشاهده وضعیت منابع موجود در کلاستر و اطمینان از صحت پیکربندی، از دستور pcs resource status استفاده کنید:

   pcs resource status
   

5. در صورت نیاز به حذف یک منبع، می‌توانید از دستور pcs resource delete استفاده کنید:

   pcs resource delete MyIP
   

جمع‌بندی

پیکربندی منابع در Pacemaker از طریق ابزارهای crm configure و pcs resource create بسیار انعطاف‌پذیر است. دستور crm configure بیشتر برای کاربران با تجربه در محیط‌های قدیمی‌تر استفاده می‌شود، در حالی که دستور pcs resource create گزینه‌ای ساده‌تر و کاربرپسندتر است که برای مدیریت منابع در Pacemaker مناسب‌تر می‌باشد. به‌طور کلی، این دستورات به شما این امکان را می‌دهند که منابع مختلف مانند IP‌ها، فایل‌سیستم‌ها، سرویس‌ها و برنامه‌ها را به‌طور دقیق و بدون وقفه پیکربندی کرده و مدیریت کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 2. شبیه‌سازی خرابی‌ها”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”اهمیت شبیه‌سازی خرابی‌ها برای آزمایش واکنش‌های کلاستر” subtitle=”توضیحات کامل”]شبیه‌سازی خرابی‌ها در کلاستر یکی از مهم‌ترین مراحل برای ارزیابی واکنش سیستم به شرایط بحرانی و اطمینان از قابلیت‌های Failover و Failback است. این فرآیند به مدیران سیستم این امکان را می‌دهد که اطمینان حاصل کنند که کلاستر در صورت بروز خرابی یا از دست دادن یکی از گره‌ها به درستی واکنش نشان می‌دهد و از منابع به‌درستی محافظت می‌شود. در این بخش، به بررسی اهمیت شبیه‌سازی خرابی‌ها و نحوه اجرای آن در کلاسترهای مبتنی بر Pacemaker پرداخته خواهد شد.

1. ارزیابی قابلیت‌های Failover

Failover به فرآیندی اطلاق می‌شود که در آن، زمانی که یک گره در کلاستر از کار می‌افتد، بار منابع به گره‌های سالم دیگر منتقل می‌شود. شبیه‌سازی خرابی‌ها به شما این امکان را می‌دهد که بررسی کنید که آیا فرآیند Failover به درستی عمل می‌کند یا خیر. با شبیه‌سازی خرابی، می‌توانید از عملکرد صحیح انتقال منابع، برقراری ارتباطات و اجرای فرآیندها در گره‌های دیگر اطمینان حاصل کنید.

برای مثال، می‌توانید از دستور pcs resource move برای شبیه‌سازی حرکت یک منبع از یک گره به گره دیگر استفاده کنید:

pcs resource move MyIP <destination-node>

این دستور به طور موقت منبع MyIP را از گره فعلی به گره مقصد منتقل می‌کند و شما می‌توانید مشاهده کنید که سیستم چگونه به این تغییر واکنش نشان می‌دهد.

2. ارزیابی قابلیت‌های Failback

Failback به فرآیندی اطلاق می‌شود که در آن پس از برطرف شدن مشکل گره اصلی، منابع به گره اصلی بازمی‌گردند. این فرآیند نیز باید به‌طور دقیق آزمایش شود تا مطمئن شوید که منابع به‌درستی به گره اصلی بازمی‌گردند و هیچ تداخلی در اجرای سرویس‌ها به وجود نمی‌آید.

برای شبیه‌سازی Failback در Pacemaker، می‌توانید از دستور pcs resource move دوباره استفاده کنید تا منبع را به گره اصلی برگردانید:

pcs resource move MyIP --clear

این دستور منبع MyIP را به گره اصلی برمی‌گرداند و اطمینان می‌دهد که فرآیند Failback به درستی انجام می‌شود.

3. بررسی عملکرد خودکار و دستی منابع در حالت خرابی

شبیه‌سازی خرابی‌ها نه تنها به بررسی فرآیندهای Failover و Failback کمک می‌کند بلکه عملکرد خودکار و دستی منابع در مواقع خرابی را نیز ارزیابی می‌کند. با این شبیه‌سازی‌ها، شما می‌توانید بررسی کنید که آیا منابع به‌طور خودکار به گره‌های دیگر منتقل می‌شوند یا نیاز به مداخله دستی دارند. همچنین، بررسی می‌کنید که آیا عملکرد سرویس‌ها به درستی بازیابی می‌شود یا خیر.

4. شبیه‌سازی خرابی‌های شبکه و گره‌ها

شبیه‌سازی خرابی‌ها همچنین شامل بررسی خرابی‌های شبکه و گره‌ها است. به عنوان مثال، می‌توانید با استفاده از دستورات pcs node standby یا pcs node unstandby، گره‌ها را به‌طور موقت غیرفعال کنید و وضعیت کلاستر را از نظر واکنش به خرابی‌های شبکه یا گره‌ها آزمایش کنید:

برای غیرفعال کردن گره:

pcs node standby <node-name>

برای فعال کردن گره مجدد:

pcs node unstandby <node-name>

این دستورات به شما کمک می‌کنند که عملکرد کلاستر را در شرایط مختلف شبیه‌سازی کنید و مطمئن شوید که تمام اجزاء کلاستر به‌درستی به شرایط خرابی واکنش نشان می‌دهند.

جمع‌بندی

شبیه‌سازی خرابی‌ها برای آزمایش واکنش‌های کلاستر یک ابزار ضروری برای اطمینان از عملکرد صحیح سیستم در شرایط بحرانی است. این فرآیند نه تنها به شما کمک می‌کند تا Failover و Failback را آزمایش کنید، بلکه عملکرد سیستم را در شرایط مختلف خرابی و از دست دادن گره‌ها ارزیابی می‌کند. با استفاده از دستورات مختلف pcs و crm، می‌توانید وضعیت منابع، گره‌ها و شبکه را شبیه‌سازی کرده و از عملکرد بهینه و بدون خطای کلاستر خود اطمینان حاصل کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”شبیه‌سازی خرابی منابع (resource failure) با استفاده از دستورات crm resource fail یا pcs resource stop” subtitle=”توضیحات کامل”]شبیه‌سازی خرابی منابع یکی از تکنیک‌های مهم برای ارزیابی واکنش کلاستر به شرایط بحرانی است. این شبیه‌سازی‌ها به مدیران سیستم کمک می‌کنند تا عملکرد کلاستر را در صورت از دست دادن منابع ارزیابی کرده و اطمینان حاصل کنند که سیستم به‌درستی فرآیندهای Failover و Failback را انجام می‌دهد. در این بخش، به بررسی روش‌های شبیه‌سازی خرابی منابع با استفاده از دستورات crm resource fail و pcs resource stop پرداخته خواهد شد.

1. شبیه‌سازی خرابی منابع با استفاده از دستور crm resource fail

دستور crm resource fail به شما این امکان را می‌دهد که یک منبع خاص را به‌طور مصنوعی دچار خرابی کنید. این دستور معمولاً برای شبیه‌سازی خرابی منابع در کلاسترهای Pacemaker و بررسی واکنش کلاستر به آن استفاده می‌شود. این دستور باعث می‌شود که کلاستر منابع را به گره‌های سالم دیگر منتقل کند و فرآیند Failover را آزمایش کنید.

برای شبیه‌سازی خرابی یک منبع خاص، می‌توانید از دستور زیر استفاده کنید:

crm resource fail <resource-name>

به‌عنوان مثال، اگر منبع IP به نام MyIP دارید و می‌خواهید آن را دچار خرابی کنید، دستور زیر را وارد کنید:

crm resource fail MyIP

این دستور منبع MyIP را به‌طور مصنوعی دچار خرابی می‌کند و باعث می‌شود که کلاستر فرآیند Failover را آغاز کند و منبع را به گره‌های دیگر منتقل کند.

2. شبیه‌سازی خرابی منابع با استفاده از دستور pcs resource stop

دستور pcs resource stop به شما این امکان را می‌دهد که یک منبع خاص را به‌طور دستی متوقف کنید. این دستور برای شبیه‌سازی خرابی منابع و بررسی رفتار کلاستر در چنین شرایطی بسیار مفید است. پس از اجرای این دستور، کلاستر باید فرآیند Failover را به‌طور خودکار اجرا کند و منابع را به گره‌های سالم دیگر منتقل کند.

برای متوقف کردن یک منبع خاص، می‌توانید از دستور زیر استفاده کنید:

pcs resource stop <resource-name>

برای مثال، برای متوقف کردن منبع MyIP، دستور زیر را وارد کنید:

pcs resource stop MyIP

پس از اجرای این دستور، کلاستر به‌طور خودکار منابع را به گره‌های دیگر منتقل خواهد کرد و شما می‌توانید عملکرد سیستم را در مواجهه با خرابی این منبع مشاهده کنید.

3. بررسی وضعیت منابع پس از شبیه‌سازی خرابی

پس از شبیه‌سازی خرابی منابع، می‌توانید از دستورات زیر برای بررسی وضعیت منابع و گره‌ها در کلاستر استفاده کنید:

برای بررسی وضعیت منابع:

pcs status

این دستور اطلاعات دقیقی در مورد وضعیت منابع، گره‌ها، و سرویس‌های موجود در کلاستر به شما می‌دهد. شما می‌توانید بررسی کنید که آیا منبع MyIP به‌درستی به گره‌های سالم منتقل شده است یا خیر.

برای بررسی وضعیت خاص یک منبع:

pcs resource status <resource-name>

برای مثال:

pcs resource status MyIP

4. بازیابی منابع پس از شبیه‌سازی خرابی

پس از شبیه‌سازی خرابی و بررسی واکنش کلاستر، می‌توانید منابع را دوباره فعال کنید و به گره اصلی بازگردانید. برای این کار از دستور pcs resource start استفاده می‌کنید.

برای فعال‌سازی مجدد یک منبع، دستور زیر را وارد کنید:

pcs resource start <resource-name>

برای مثال:

pcs resource start MyIP

این دستور منبع MyIP را دوباره فعال کرده و آن را به گره اصلی باز می‌گرداند.

جمع‌بندی

شبیه‌سازی خرابی منابع با استفاده از دستورات crm resource fail و pcs resource stop ابزار قدرتمندی برای ارزیابی واکنش کلاستر در شرایط بحرانی است. با استفاده از این دستورات، می‌توانید مطمئن شوید که کلاستر به‌درستی از فرآیند Failover و Failback پشتیبانی می‌کند و منابع به‌درستی به گره‌های سالم منتقل می‌شوند. همچنین، این شبیه‌سازی‌ها به شما این امکان را می‌دهند که عملکرد کلاستر را در شرایط مختلف تست کنید و از پایداری و قابلیت اطمینان سیستم خود اطمینان حاصل کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”شبیه‌سازی خرابی گره (node failure) و بررسی انتقال خودکار منابع به گره دیگر” subtitle=”توضیحات کامل”]شبیه‌سازی خرابی گره یکی از روش‌های اساسی برای آزمایش عملکرد کلاستر در مواجهه با خرابی یک گره است. با شبیه‌سازی خرابی یک گره، می‌توانیم واکنش‌های سیستم را بررسی کنیم و اطمینان حاصل کنیم که منابع به‌درستی به گره‌های دیگر منتقل می‌شوند و فرآیند Failover به‌طور صحیح انجام می‌شود. در این بخش، به بررسی نحوه شبیه‌سازی خرابی گره و انتقال خودکار منابع به گره دیگر پرداخته می‌شود.

1. شبیه‌سازی خرابی گره

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

روش‌های شبیه‌سازی خرابی گره

1. خاموش کردن گره به‌طور دستی
   ساده‌ترین روش برای شبیه‌سازی خرابی گره خاموش کردن آن است. با خاموش کردن گره، Pacemaker باید منابع را به گره‌های سالم دیگر منتقل کند.

   برای خاموش کردن گره به‌طور دستی، از دستور زیر استفاده کنید:

   sudo shutdown -h now
   

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

2. متوقف کردن سرویس‌های مربوط به گره
   به‌جای خاموش کردن کامل گره، می‌توانید فقط سرویس‌های مربوط به گره را متوقف کنید. این روش نیز به‌طور مشابه باعث شبیه‌سازی خرابی گره خواهد شد. برای متوقف کردن سرویس‌ها می‌توانید از دستور زیر استفاده کنید:

   sudo systemctl stop pacemaker
   

   این دستور سرویس Pacemaker را متوقف می‌کند و باعث می‌شود که گره دیگر نتواند منابع را مدیریت کند.

3. استفاده از دستور pcs cluster stop
   دستور pcs cluster stop به شما این امکان را می‌دهد که گره خاصی را به‌طور نرم از کلاستر خارج کنید. این روش برای شبیه‌سازی خرابی گره استفاده می‌شود بدون اینکه گره را به‌طور کامل خاموش کنید.

   برای متوقف کردن گره از کلاستر، از دستور زیر استفاده کنید:

   pcs cluster stop <node-name>
   

   به‌عنوان مثال، اگر گره به نام node1 دارید، دستور زیر را وارد کنید:

   pcs cluster stop node1
   

2. بررسی انتقال منابع پس از خرابی گره

پس از شبیه‌سازی خرابی گره، کلاستر باید به‌طور خودکار منابع را به گره‌های سالم دیگر منتقل کند. برای بررسی وضعیت انتقال منابع، می‌توانید از دستورات زیر استفاده کنید:

1. بررسی وضعیت کلاستر با دستور pcs status

   دستور pcs status اطلاعات کاملی در مورد وضعیت کلاستر و منابع موجود در گره‌های مختلف نمایش می‌دهد. پس از شبیه‌سازی خرابی گره، این دستور به شما نشان می‌دهد که منابع به گره‌های دیگر منتقل شده‌اند یا خیر.

   pcs status
   

   خروجی این دستور اطلاعاتی مانند وضعیت منابع، گره‌ها و اینکه آیا منابع به گره دیگر منتقل شده‌اند یا خیر را نشان می‌دهد.

2. بررسی وضعیت منابع با دستور pcs resource status

   اگر می‌خواهید فقط وضعیت منابع خاص را بررسی کنید، می‌توانید از دستور pcs resource status استفاده کنید. برای مثال، برای بررسی وضعیت منبع MyIP:

   pcs resource status MyIP
   

   این دستور به شما اطلاعات دقیق‌تری در مورد وضعیت منبع خاص و اینکه آیا به گره سالم منتقل شده است یا خیر، ارائه می‌دهد.

3. بازیابی گره و بازگشت منابع به آن

پس از شبیه‌سازی خرابی گره و بررسی واکنش کلاستر، می‌توانید گره را به کلاستر بازگردانید و منابع را به آن بازگردانید. برای این کار می‌توانید از دستور pcs cluster start استفاده کنید.

برای راه‌اندازی گره و بازگشت منابع به آن، دستور زیر را وارد کنید:

pcs cluster start <node-name>

برای مثال، اگر گره به نام node1 دارید و می‌خواهید آن را مجدداً راه‌اندازی کنید:

pcs cluster start node1

پس از این دستور، کلاستر منابع را به گره باز می‌گرداند و آن را به‌عنوان گره فعال در نظر می‌گیرد.

جمع‌بندی

شبیه‌سازی خرابی گره برای ارزیابی واکنش کلاستر در شرایط بحرانی ضروری است. با استفاده از دستورات pcs cluster stop، shutdown و systemctl stop می‌توانید خرابی گره را شبیه‌سازی کرده و بررسی کنید که آیا منابع به‌درستی به گره‌های سالم منتقل می‌شوند یا خیر. پس از شبیه‌سازی خرابی گره، می‌توانید با استفاده از دستورات pcs status و pcs resource status وضعیت منابع و گره‌ها را بررسی کنید. همچنین، پس از انجام آزمایش‌ها، می‌توانید گره را به کلاستر بازگردانید و منابع را به آن بازگردانید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نحوه شبیه‌سازی خرابی شبکه یا قطع ارتباط بین گره‌ها” subtitle=”توضیحات کامل”]شبیه‌سازی خرابی شبکه یا قطع ارتباط بین گره‌ها در کلاستر برای ارزیابی عملکرد سیستم در شرایط بحرانی و برای آزمایش فرآیند Failover و Failback بسیار مهم است. قطع ارتباط بین گره‌ها می‌تواند به‌طور مؤثری آزمایش کند که آیا کلاستر می‌تواند در صورت قطع شدن ارتباط میان گره‌ها، منابع را به درستی جابه‌جا کند و واکنش مناسبی داشته باشد. در این بخش، به روش‌های مختلف شبیه‌سازی خرابی شبکه یا قطع ارتباط بین گره‌ها و بررسی اثرات آن پرداخته می‌شود.

1. شبیه‌سازی قطع ارتباط شبکه به‌طور دستی

برای شبیه‌سازی خرابی شبکه و قطع ارتباط بین گره‌ها، می‌توانید از ابزارهای مختلفی مانند iptables و ifconfig استفاده کنید تا ارتباط شبکه را به‌طور موقت قطع کنید.

1. استفاده از دستور iptables

   دستور iptables به شما این امکان را می‌دهد که بسته‌های شبکه را مسدود کنید و ارتباط بین گره‌ها را قطع کنید. برای قطع ارتباط شبکه میان دو گره از دستور زیر استفاده کنید:

   ابتدا، اتصال را از گره 1 به گره 2 قطع کنید:

   sudo iptables -A INPUT -s <IP-of-node2> -j DROP
   

   سپس، برای قطع ارتباط از گره 2 به گره 1 دستور زیر را اجرا کنید:

   sudo iptables -A INPUT -s <IP-of-node1> -j DROP
   

   این دستورات به‌طور موقت تمامی بسته‌های شبکه‌ای که از گره 1 به گره 2 و بالعکس ارسال می‌شوند را مسدود می‌کنند. این نوع شبیه‌سازی برای ارزیابی اثرات قطع ارتباط در کلاستر مفید است.

2. استفاده از دستور ifconfig

   اگر بخواهید تنها یک آداپتور شبکه خاص را غیرفعال کنید، می‌توانید از دستور ifconfig استفاده کنید:

   برای غیرفعال کردن اتصال شبکه در گره 1:

   sudo ifconfig eth0 down
   

   و برای فعال‌سازی مجدد آن:

   sudo ifconfig eth0 up
   

   با این دستور، اتصال شبکه برای آداپتور eth0 در گره 1 قطع می‌شود و می‌توانید وضعیت واکنش کلاستر را بررسی کنید.

2. بررسی انتقال منابع پس از قطع ارتباط

پس از قطع ارتباط میان گره‌ها، باید بررسی کنید که آیا Failover به‌درستی انجام شده است یا خیر. برای این کار می‌توانید از دستورات زیر استفاده کنید:

1. بررسی وضعیت کلاستر با دستور pcs status

   دستور pcs status اطلاعات کاملی در مورد وضعیت کلاستر و منابع موجود در گره‌های مختلف نمایش می‌دهد. پس از قطع ارتباط، می‌توانید از این دستور برای بررسی وضعیت انتقال منابع استفاده کنید.

   دستور زیر وضعیت کلاستر را نمایش می‌دهد:

   pcs status
   

   این دستور به شما نشان می‌دهد که منابع در گره‌های فعال دیگر منتقل شده‌اند یا خیر.

2. بررسی وضعیت منابع با دستور pcs resource status

   برای بررسی وضعیت منابع خاص، می‌توانید از دستور pcs resource status استفاده کنید. به‌عنوان مثال، برای بررسی وضعیت منبع MyIP:

   pcs resource status MyIP
   

   این دستور به شما اطلاعات دقیق‌تری در مورد وضعیت منابع خاص و اینکه آیا به گره دیگر منتقل شده است یا خیر، ارائه می‌دهد.

3. شبیه‌سازی خرابی شبکه در صورت استفاده از ابزارهای شبکه‌ای

اگر از ابزارهایی مانند tc (traffic control) برای شبیه‌سازی تأخیر یا از دست رفتن بسته‌ها استفاده می‌کنید، می‌توانید شبکه را به‌طور کنترل‌شده‌ای قطع یا تأخیر ایجاد کنید.

1. استفاده از دستور tc برای شبیه‌سازی تأخیر در شبکه

   برای شبیه‌سازی تأخیر شبکه بین گره‌ها، می‌توانید از دستور tc برای افزودن تأخیر به بسته‌های شبکه استفاده کنید. برای افزودن تأخیر 100 میلی‌ثانیه به ارتباط بین گره 1 و گره 2، دستور زیر را اجرا کنید:

   sudo tc qdisc add dev eth0 root netem delay 100ms
   

   این دستور تأخیر 100 میلی‌ثانیه را به تمامی بسته‌های ارسالی از گره 1 به گره 2 اعمال می‌کند. برای حذف این تأخیر:

   sudo tc qdisc del dev eth0 root netem
   

   این روش برای شبیه‌سازی تأخیر در ارتباط شبکه مفید است و به شما کمک می‌کند تا اثرات تأخیر شبکه را در زمان Failover ارزیابی کنید.

2. استفاده از دستور tc برای شبیه‌سازی از دست رفتن بسته‌ها

   اگر بخواهید شبیه‌سازی خرابی کامل شبکه را انجام دهید و از دست رفتن بسته‌ها را آزمایش کنید، می‌توانید از دستور tc برای رها کردن بسته‌ها استفاده کنید:

   برای شبیه‌سازی از دست رفتن 50% از بسته‌ها، دستور زیر را اجرا کنید:

   sudo tc qdisc add dev eth0 root netem loss 50%
   

   این دستور 50% از بسته‌های ارسال‌شده را رها می‌کند و تأثیرات این کار بر کلاستر را بررسی خواهید کرد.

4. بازیابی شبکه و بازگشت به حالت عادی

پس از آزمایش‌های لازم، می‌توانید شبکه را به حالت اولیه بازگردانید:

1. حذف محدودیت‌های شبکه‌ای با دستور iptables

   برای حذف محدودیت‌های اعمال‌شده با iptables، از دستور زیر استفاده کنید:

   sudo iptables -D INPUT -s <IP-of-node2> -j DROP
   sudo iptables -D INPUT -s <IP-of-node1> -j DROP
   

2. فعال‌سازی مجدد آداپتور شبکه با دستور ifconfig

   برای فعال‌سازی مجدد آداپتور شبکه:

   sudo ifconfig eth0 up
   

جمع‌بندی

شبیه‌سازی خرابی شبکه یا قطع ارتباط بین گره‌ها یک روش کارآمد برای آزمایش واکنش‌های کلاستر در زمان بروز مشکلات ارتباطی است. با استفاده از ابزارهایی مانند iptables، ifconfig و tc، می‌توان به‌طور دستی ارتباط شبکه را قطع یا شبیه‌سازی تأخیر در شبکه را انجام داد و بررسی کرد که آیا کلاستر به‌درستی منابع را جابه‌جا می‌کند. پس از انجام آزمایش‌ها، می‌توانید شبکه را به حالت اولیه بازگردانید و وضعیت کلاستر و منابع را با استفاده از دستورات pcs status و pcs resource status بررسی کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 3. تنظیمات Failover و Failback”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تعریف Failover و Failback در کلاسترهای HA” subtitle=”توضیحات کامل”]در کلاسترهای High Availability (HA)، یکی از مهم‌ترین ویژگی‌ها، توانایی پاسخگویی به خرابی‌های گره‌ها یا منابع است. این ویژگی به طور خودکار منابع یا خدمات را به گره‌ها یا منابع دیگر منتقل می‌کند تا سیستم همچنان در دسترس باشد. در اینجا دو مفهوم اصلی در این زمینه وجود دارد که به آن‌ها می‌پردازیم: Failover و Failback.

1. Failover چیست؟

Failover به فرایند خودکار انتقال منابع و خدمات به گره یا سرور سالم دیگر در صورت بروز خرابی در گره یا سرور اولیه اشاره دارد. این فرایند معمولاً در کلاسترهای HA برای جلوگیری از خرابی‌های قابل مشاهده و تأثیرات منفی بر کاربران و سیستم‌ها استفاده می‌شود.

به‌طور مثال، اگر گره‌ای در یک کلاستر HA دچار خرابی شود، Failover به‌طور خودکار منابع آن گره را به گره سالم دیگر منتقل می‌کند تا سرویس‌دهی به کاربران ادامه پیدا کند.

2. Failback چیست؟

Failback به فرایند بازگشت منابع از گره سالم به گره اصلی که بعد از خرابی مجدداً به وضعیت پایدار رسیده است، اطلاق می‌شود. این فرایند پس از حل مشکل در گره اصلی انجام می‌شود تا منابع دوباره به گره اصلی منتقل شوند.

در واقع، Failover فرایند انتقال به گره دوم است، در حالی که Failback فرایند انتقال منابع به گره اصلی پس از بازیابی آن است.

نحوه پیکربندی Failover و Failback در Pacemaker

برای پیاده‌سازی Failover و Failback به طور مؤثر در کلاسترهای HA که از Pacemaker استفاده می‌کنند، لازم است تنظیمات خاصی انجام دهید. این تنظیمات می‌توانند شامل تنظیم اولویت منابع و گره‌ها، استفاده از قوانین location constraints و colocation constraints برای تعیین نحوه جابه‌جایی منابع در زمان خرابی و بعد از آن باشند.

پیکربندی Failover با Pacemaker

1. ایجاد و تنظیم منبع با دستور pcs resource create

   برای شروع، ابتدا باید منابعی که می‌خواهید در کلاستر مدیریت شوند، ایجاد کنید. برای مثال، فرض کنید که می‌خواهید یک IP مجازی را به منابع اضافه کنید که به‌صورت failover در گره‌ها جابه‌جا شود.

   دستور زیر برای ایجاد یک IP مجازی با نام VirtualIP در کلاستر استفاده می‌شود:

   pcs resource create VirtualIP IPaddr2 ip=<Virtual_IP_address> cidr_netmask=<netmask> op monitor interval=30s
   

   مسیر فایل: این تنظیمات در فایل /etc/corosync/corosync.conf یا /etc/pacemaker/pacemaker.conf اعمال می‌شود.

2. تنظیمات Location Constraint برای Failover

   برای تعیین اینکه کدام گره‌ها باید در صورت خرابی گره اول، منابع را دریافت کنند، می‌توانید از location constraints استفاده کنید. این دستور به منابع اجازه می‌دهد تا تنها بر روی گره‌های خاصی اجرا شوند.

   به‌عنوان مثال، فرض کنید می‌خواهید منبع VirtualIP تنها بر روی گره Node1 فعال باشد و در صورت خرابی این گره، به گره Node2 منتقل شود:

   دستور زیر این تنظیمات را اعمال می‌کند:

   pcs constraint location VirtualIP prefers Node1=INFINITY
   pcs constraint location VirtualIP prefers Node2=INFINITY
   

   مسیر فایل: این تنظیمات در /etc/corosync/corosync.conf یا فایل تنظیمات مربوط به Pacemaker اعمال می‌شود.

3. استفاده از pcs status برای بررسی وضعیت Failover

   برای بررسی وضعیت منابع در حال حاضر و اینکه آیا فرآیند Failover به درستی اجرا شده است، از دستور زیر استفاده کنید:

   pcs status
   

   این دستور نشان می‌دهد که منابع در حال حاضر روی کدام گره‌ها قرار دارند و آیا منابع به درستی از گره‌ای به گره دیگر منتقل شده‌اند یا خیر.

پیکربندی Failback با Pacemaker

1. پیکربندی Failback

   بعد از اینکه گره اصلی به حالت پایدار بازگشت، می‌خواهید منابع به گره اصلی منتقل شوند. این کار را می‌توان با استفاده از resource stickiness انجام داد.

   در اینجا یک مثال از resource stickiness آورده شده است:

   pcs resource meta VirtualIP resource-stickiness=100
   

   با این تنظیم، اگر گره اصلی (Node1) بازیابی شود، منابع به طور خودکار به آن منتقل می‌شوند. عدد 100 میزان چسبندگی به گره اصلی را نشان می‌دهد.

2. **تنظیم **colocation constraint برای Failback

   در صورتی که بخواهید منابع به طور همزمان روی گره‌های خاصی در صورت بازیابی گره اصلی منتقل شوند، از colocation constraint استفاده می‌کنید. این دستور به منابع می‌گوید که در کدام گره‌ها هم‌زمان باید اجرا شوند.

   دستور زیر منابع را در صورت خرابی و بازیابی به گره‌های موردنظر جابه‌جا می‌کند:

   pcs constraint colocation add VirtualIP with MyService INFINITY
   

   مسیر فایل: این تغییرات نیز در /etc/corosync/corosync.conf و فایل‌های تنظیمات مربوط به Pacemaker اعمال می‌شود.

3. بررسی وضعیت Failback با دستور pcs status

   برای بررسی وضعیت اجرای Failback و اطمینان از اینکه منابع به درستی به گره اصلی بازگشته‌اند، می‌توانید از دستور زیر استفاده کنید:

   pcs status
   

آزمایش Failover و Failback

برای تست Failover و Failback، می‌توانید به‌صورت دستی گره‌ها را خاموش کرده و مشاهده کنید که آیا منابع به‌طور خودکار به گره دیگر منتقل می‌شوند و سپس بررسی کنید که پس از بازیابی گره اصلی، منابع به آن بازگشتند یا خیر.

1. شبیه‌سازی Failover با دستور pcs resource move

   برای شبیه‌سازی Failover، می‌توانید منابع را به‌طور دستی به گره دیگر منتقل کنید:

   pcs resource move VirtualIP Node2
   

   پس از این دستور، باید منابع به گره Node2 منتقل شوند. برای بازگشت به گره اصلی:

   pcs resource move VirtualIP Node1
   

2. شبیه‌سازی خرابی گره

   برای شبیه‌سازی خرابی گره، از دستور زیر برای خاموش کردن گره استفاده کنید:

   pcs node standby Node1
   

   این دستور گره Node1 را در حالت standby قرار می‌دهد و منابع باید به گره دیگر منتقل شوند.

3. بازگشت گره به حالت فعال

   پس از بازگشت گره به حالت فعال، می‌توانید با دستور زیر آن را از حالت standby خارج کنید:

   pcs node clear Node1
   

جمع‌بندی

در این بخش، Failover و Failback در کلاسترهای HA توضیح داده شد. Failover فرایند انتقال منابع از گره خراب به گره سالم است، در حالی که Failback فرایند بازگشت منابع به گره اصلی پس از بازیابی آن است. با استفاده از دستورات pcs resource create، pcs resource meta و pcs constraint location می‌توان این فرایندها را پیکربندی کرد. برای آزمایش این فرایندها نیز می‌توان از دستورات pcs resource move و pcs node standby استفاده کرد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”پیکربندی سیاست‌های Failover برای انتقال منابع به گره‌های سالم” subtitle=”توضیحات کامل”]در کلاسترهای High Availability (HA)، پیکربندی سیاست‌های Failover یکی از مهم‌ترین بخش‌هاست که به‌طور خودکار منابع را در صورت خرابی گره به گره‌های سالم منتقل می‌کند. این فرایند به جلوگیری از خرابی‌های طولانی‌مدت و از دست رفتن خدمات کمک می‌کند و اطمینان حاصل می‌شود که منابع همیشه در دسترس باقی بمانند.

برای پیکربندی صحیح سیاست‌های Failover در کلاسترهای که از Pacemaker استفاده می‌کنند، نیاز است که سیاست‌های مختلفی اعمال شود تا انتقال منابع به گره‌های سالم و قابلیت بازیابی به درستی انجام شود.

گام‌های پیکربندی سیاست‌های Failover در Pacemaker

1. ایجاد منابع با استفاده از دستور pcs resource create

اولین گام در پیکربندی سیاست‌های Failover، ایجاد منابعی است که قرار است به‌طور خودکار در صورت خرابی گره‌ها منتقل شوند. برای مثال، فرض کنید یک IP مجازی داریم که می‌خواهیم آن را بین گره‌ها منتقل کنیم.

دستور زیر برای ایجاد یک IP مجازی در کلاستر استفاده می‌شود:

pcs resource create VirtualIP IPaddr2 ip=192.168.1.100 cidr_netmask=24 op monitor interval=30s

این دستور یک منبع IP مجازی با آدرس 192.168.1.100 را در کلاستر ایجاد می‌کند که به‌طور خودکار هر ۳۰ ثانیه وضعیت آن بررسی می‌شود.

مسیر فایل: تنظیمات این دستور معمولاً در فایل /etc/pacemaker/pacemaker.conf یا /etc/corosync/corosync.conf ذخیره می‌شود.

2. پیکربندی Location Constraints برای Failover

با استفاده از location constraints می‌توان تعیین کرد که کدام منابع بر روی گره‌های خاص اجرا شوند و در صورت خرابی به کدام گره‌ها منتقل شوند. این قابلیت به شما این امکان را می‌دهد که اولویت‌بندی‌ها و سیاست‌های انتقال منابع را مشخص کنید.

برای مثال، اگر بخواهید منبع VirtualIP ابتدا روی گره Node1 اجرا شود و در صورت خرابی آن به گره Node2 منتقل شود، از دستور زیر استفاده می‌کنید:

pcs constraint location VirtualIP prefers Node1=INFINITY
pcs constraint location VirtualIP prefers Node2=INFINITY

در اینجا INFINITY نشان‌دهنده اولویت بسیار بالای گره‌های Node1 و Node2 برای قرارگیری این منبع است.

مسیر فایل: این تنظیمات در فایل‌های /etc/pacemaker/pacemaker.conf یا فایل‌های مشابه در /etc/corosync/corosync.conf اعمال می‌شود.

3. پیکربندی Resource Stickiness برای Failover

Resource Stickiness به معنی تنظیم چسبندگی منابع است، به این معنی که منابع ترجیح می‌دهند روی گره‌ای که قبلاً در آن قرار داشته‌اند، باقی بمانند. این تنظیم به شما کمک می‌کند تا از جابجایی مکرر منابع جلوگیری کنید و منابع تنها در صورت لزوم به گره دیگری منتقل شوند.

برای پیکربندی resource stickiness، دستور زیر را وارد کنید:

pcs resource meta VirtualIP resource-stickiness=100

عدد 100 نشان‌دهنده این است که VirtualIP تمایل زیادی به باقی ماندن بر روی گره فعلی دارد. اگر گره خراب شود، منابع به گره دیگر منتقل خواهند شد، اما پس از بازیابی گره اصلی، منابع به آن بازخواهند گشت.

مسیر فایل: این تنظیمات در /etc/pacemaker/pacemaker.conf ذخیره می‌شود.

4. پیکربندی Colocation Constraints برای Failover

Colocation constraints برای تعیین اینکه کدام منابع باید در کنار یکدیگر اجرا شوند، استفاده می‌شوند. این تنظیمات به شما این امکان را می‌دهند که به‌طور دقیق کنترل کنید که در صورت خرابی یک گره، منابع به‌طور خودکار به گره‌های مناسب انتقال یابند و در کنار یکدیگر قرار گیرند.

برای مثال، اگر منبع VirtualIP و MyService را بخواهید که به‌طور هم‌زمان در یک گره قرار گیرند، دستور زیر را وارد می‌کنید:

pcs constraint colocation add VirtualIP with MyService INFINITY

این دستور به این معنی است که VirtualIP و MyService باید هم‌زمان روی یک گره قرار گیرند. اگر VirtualIP به گره دیگری منتقل شود، MyService نیز به همان گره منتقل خواهد شد.

مسیر فایل: این تنظیمات معمولاً در /etc/pacemaker/pacemaker.conf قرار می‌گیرند.

5. نظارت بر وضعیت Failover

برای نظارت بر وضعیت منابع و مطمئن شدن از اینکه منابع به‌درستی از یک گره به گره دیگر منتقل می‌شوند، می‌توانید از دستور زیر استفاده کنید:

pcs status

این دستور وضعیت تمامی منابع موجود در کلاستر را نشان می‌دهد و به شما اطلاع می‌دهد که منابع روی کدام گره قرار دارند و آیا به‌درستی منتقل شده‌اند یا خیر.

6. شبیه‌سازی Failover

برای تست Failover و اطمینان از اینکه سیاست‌ها به درستی پیکربندی شده‌اند، می‌توانید از دستور زیر برای انتقال منابع به گره دیگر استفاده کنید:

pcs resource move VirtualIP Node2

این دستور منبع VirtualIP را به گره Node2 منتقل می‌کند. پس از انتقال، منابع باید بر روی Node2 فعال شوند.

7. بررسی وضعیت انتقال منابع

برای بررسی وضعیت انتقال منابع، از دستور زیر استفاده کنید:

pcs resource status

این دستور به شما اطلاع می‌دهد که منابع در کدام گره‌ها قرار دارند و آیا سیاست‌های Failover به درستی اعمال شده‌اند یا خیر.

8. بازیابی منابع به گره اصلی

اگر گره اصلی به حالت پایدار برگشت، می‌توانید منابع را به گره اصلی بازگردانید:

pcs resource move VirtualIP Node1

این دستور منابع را به گره Node1 باز می‌گرداند. در صورتی که گره Node1 بازگشته و در حالت پایدار قرار داشته باشد، منابع به آن منتقل می‌شوند.

جمع‌بندی

در این بخش، پیکربندی سیاست‌های Failover برای انتقال منابع به گره‌های سالم و مدیریت آن‌ها توضیح داده شد. با استفاده از دستوراتی همچون pcs resource create، pcs constraint location، pcs resource meta و pcs constraint colocation add، می‌توان منابع را به‌طور خودکار به گره‌های سالم منتقل کرد. همچنین، با استفاده از دستورات نظارتی مانند pcs status و pcs resource move می‌توان وضعیت کلاستر را کنترل کرده و در صورت خرابی گره‌ها، منابع را به گره‌های سالم منتقل کرد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”بررسی سیاست‌های Failback برای بازگشت منابع به گره اولیه پس از رفع خرابی” subtitle=”توضیحات کامل”]Failback به معنای بازگشت خودکار منابع از گره پشتیبان به گره اصلی پس از رفع خرابی است. در یک سیستم کلاستر High Availability (HA) که از Pacemaker برای مدیریت منابع استفاده می‌کند، سیاست‌های Failback بسیار مهم هستند تا اطمینان حاصل شود که پس از بازیابی گره خراب‌شده، منابع به‌طور خودکار به آن گره باز می‌گردند. این سیاست‌ها نه تنها برای حفظ عملکرد بهینه کلاستر مفید هستند، بلکه کمک می‌کنند تا منابع به گره اصلی که بهترین منابع را برای اجرای آن دارند، بازگردند.

در این بخش، به بررسی چگونگی پیکربندی و استفاده از سیاست‌های Failback در Pacemaker خواهیم پرداخت.

گام‌های پیکربندی Failback در Pacemaker

1. پیکربندی سیاست‌های Failback با استفاده از دستور pcs resource meta

با استفاده از دستور pcs resource meta می‌توان مشخص کرد که منابع باید پس از رفع خرابی به گره اصلی بازگردند. برای این کار، شما می‌توانید از گزینه migration-threshold استفاده کنید که مشخص می‌کند منابع چقدر باید از گره اصلی دور شوند تا به گره دیگری منتقل شوند. با این گزینه می‌توان اطمینان حاصل کرد که پس از رفع خرابی، منابع به گره اصلی باز می‌گردند.

برای مثال، دستور زیر را در نظر بگیرید:

pcs resource meta VirtualIP migration-threshold=1

در این دستور، migration-threshold=1 به این معناست که VirtualIP در صورتی به گره دوم منتقل خواهد شد که گره اصلی 1 بار تلاش کند و نتواند منابع را اداره کند. بعد از رفع خرابی، VirtualIP به‌طور خودکار به گره اصلی باز می‌گردد.

مسیر فایل: این تنظیمات در فایل /etc/pacemaker/pacemaker.conf ذخیره می‌شوند.

2. پیکربندی سیاست‌های Failback با استفاده از دستور pcs resource stickiness

یکی از راه‌های دیگر برای پیکربندی Failback استفاده از Resource Stickiness است که باعث می‌شود منابع تمایل بیشتری به باقی ماندن در گره‌ای داشته باشند که قبلاً در آن قرار داشته‌اند. این تنظیم کمک می‌کند که منابع پس از انتقال به گره پشتیبان، پس از رفع خرابی گره اصلی، به‌طور خودکار به گره اصلی بازگردند.

برای پیکربندی Failback با استفاده از Resource Stickiness، دستور زیر را وارد کنید:

pcs resource meta VirtualIP resource-stickiness=100

در اینجا عدد 100 نشان‌دهنده این است که VirtualIP پس از انتقال به گره دوم، تمایل زیادی به بازگشت به گره اصلی (در صورت رفع خرابی آن) دارد.

مسیر فایل: این تنظیمات در /etc/pacemaker/pacemaker.conf قرار می‌گیرند.

3. پیکربندی Location Constraints برای Failback

یکی دیگر از روش‌های پیکربندی Failback استفاده از location constraints است. شما می‌توانید برای منابع تعیین کنید که پس از خرابی به کدام گره بازگردند. این تنظیمات به شما این امکان را می‌دهند که دقیقاً مشخص کنید که منابع باید در گره اصلی خود پس از بازیابی قرار بگیرند.

برای مثال، برای اطمینان از بازگشت VirtualIP به Node1 پس از رفع خرابی آن، می‌توانید از دستور زیر استفاده کنید:

pcs constraint location VirtualIP prefers Node1=INFINITY

در اینجا INFINITY نشان‌دهنده این است که منبع VirtualIP پس از رفع خرابی باید به Node1 بازگردد.

مسیر فایل: این تنظیمات در /etc/pacemaker/pacemaker.conf قرار می‌گیرند.

4. شبیه‌سازی Failback

برای شبیه‌سازی و تست فرآیند Failback و اطمینان از عملکرد صحیح آن، می‌توانید از دستورات زیر برای شبیه‌سازی خرابی و بازگشت منابع استفاده کنید:

1. ابتدا منابع را به گره پشتیبان انتقال دهید:

   pcs resource move VirtualIP Node2
   

2. سپس گره Node2 را به حالت خرابی درآورید یا غیرفعال کنید (برای شبیه‌سازی خرابی):

   pcs node standby Node2
   

3. پس از رفع خرابی، منابع باید به‌طور خودکار به گره اصلی Node1 بازگردند. برای اطمینان از این که این اتفاق می‌افتد، دستور زیر را وارد کنید:

   pcs resource move VirtualIP Node1
   

5. نظارت بر وضعیت Failback

برای بررسی وضعیت Failback و اطمینان از بازگشت صحیح منابع به گره اصلی، می‌توانید از دستور زیر استفاده کنید:

pcs status

این دستور به شما نشان می‌دهد که منابع کجا قرار دارند و آیا پس از خرابی به گره اصلی بازگشته‌اند یا خیر.

6. بازیابی منابع به گره اصلی

اگر گره اصلی به وضعیت سالم برگشته باشد، می‌توانید منابع را به‌طور دستی به گره اصلی بازگردانید:

pcs resource move VirtualIP Node1

این دستور منابع را به گره Node1 باز می‌گرداند، اگر این گره پس از خرابی به وضعیت سالم برگشته باشد.

جمع‌بندی

در این بخش، پیکربندی سیاست‌های Failback برای بازگشت منابع به گره اولیه پس از رفع خرابی مورد بررسی قرار گرفت. با استفاده از دستورات pcs resource meta migration-threshold و pcs resource meta resource-stickiness می‌توان سیاست‌های Failback را پیکربندی کرد تا منابع به‌طور خودکار به گره اصلی بازگردند. همچنین، با استفاده از location constraints می‌توان مشخص کرد که منابع پس از رفع خرابی به گره اصلی باز گردند. این تنظیمات به شما کمک می‌کنند تا اطمینان حاصل کنید که منابع در دسترس و پایدار باقی می‌مانند و پس از خرابی به‌طور خودکار به گره اصلی باز می‌گردند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تنظیمات مربوط به فواصل زمانی و شرایط زمانی برای Failover و Failback” subtitle=”توضیحات کامل”]یکی از جنبه‌های مهم در پیکربندی کلاسترهای High Availability (HA) این است که سیستم باید در مواجهه با خرابی‌ها واکنش سریعی نشان دهد و منابع را به‌طور خودکار از گره خراب‌شده به گره سالم منتقل کند (Failover). همچنین، پس از رفع خرابی، منابع باید به‌طور خودکار به گره اصلی بازگردند (Failback). برای مدیریت این فرآیند به‌طور دقیق، می‌توان از تنظیمات فواصل زمانی و شرایط زمانی استفاده کرد. این تنظیمات در Pacemaker به شما این امکان را می‌دهند که شرایط زمانی مشخصی برای Failover و Failback ایجاد کنید.

1. تنظیم فواصل زمانی برای Failover

در Pacemaker، فواصل زمانی برای Failover معمولاً با استفاده از متغیرهای failure-timeout و migration-threshold تنظیم می‌شوند. این تنظیمات مشخص می‌کنند که پس از چه مدت زمان یا چند بار تلاش، سیستم باید منابع را به گره دیگر منتقل کند.

تنظیم failure-timeout

failure-timeout مشخص می‌کند که پس از چه مدت زمان عدم پاسخگویی از گره، Failover باید انجام شود. این مقدار را می‌توانید با استفاده از دستور زیر تنظیم کنید:

pcs resource meta <resource_name> failure-timeout=30s

در این مثال، پس از ۳۰ ثانیه عدم پاسخگویی از گره، Failover اتفاق خواهد افتاد.

مسیر فایل: این تنظیمات در /etc/pacemaker/pacemaker.conf ذخیره می‌شوند.

تنظیم migration-threshold

migration-threshold مشخص می‌کند که منابع تا چه میزان باید از گره اصلی به گره پشتیبان منتقل شوند تا Failover انجام شود. این تنظیم به شما این امکان را می‌دهد که برای منابع، محدودیت‌هایی برای مقدار شکست‌های قابل‌قبول تنظیم کنید.

برای تنظیم این محدودیت، از دستور زیر استفاده کنید:

pcs resource meta <resource_name> migration-threshold=3

در این مثال، اگر گره به مدت سه بار تلاش کند تا منابع را مدیریت کند و در هر سه بار ناموفق باشد، منابع به گره دیگری منتقل خواهند شد.

مسیر فایل: این تنظیمات در /etc/pacemaker/pacemaker.conf ذخیره می‌شوند.

2. تنظیمات برای مدیریت Failback

Failback به معنای بازگشت منابع به گره اصلی پس از رفع خرابی است. برای مدیریت دقیق این فرآیند، می‌توان فواصل زمانی و شرایط زمانی خاصی را تنظیم کرد. یکی از مهم‌ترین تنظیمات برای Failback، failback است که مشخص می‌کند منابع پس از رفع خرابی باید به گره اصلی بازگردند یا خیر.

تنظیم failback

برای فعال‌سازی Failback به‌طور خودکار پس از رفع خرابی، می‌توانید از دستور زیر استفاده کنید:

pcs resource meta <resource_name> failback=true

این دستور باعث می‌شود که پس از رفع خرابی گره اصلی، منابع به‌طور خودکار به گره اصلی بازگردند.

مسیر فایل: این تنظیمات در /etc/pacemaker/pacemaker.conf ذخیره می‌شوند.

تنظیم failback-timeout

برای تعیین مدت زمانی که باید برای بررسی سلامت گره‌ها و بازگشت منابع به گره اصلی صبر شود، می‌توانید از گزینه failback-timeout استفاده کنید. این تنظیم می‌تواند به شما کمک کند که منابع به‌طور خودکار پس از مدت زمان معینی به گره اصلی بازگردند.

برای پیکربندی این تنظیم، از دستور زیر استفاده کنید:

pcs resource meta <resource_name> failback-timeout=2m

در این مثال، منابع پس از گذشت ۲ دقیقه از رفع خرابی به گره اصلی بازخواهند گشت.

مسیر فایل: این تنظیمات در /etc/pacemaker/pacemaker.conf ذخیره می‌شوند.

3. تنظیمات فواصل زمانی برای Failover و Failback با استفاده از location constraints

شما می‌توانید با استفاده از location constraints تنظیم کنید که منابع باید پس از مدت زمانی معین به گره اصلی بازگردند یا نه. این تنظیمات به شما این امکان را می‌دهند که منابع را با اولویت‌بندی خاصی در گره‌ها قرار دهید.

برای مثال، دستور زیر می‌تواند تعیین کند که پس از ۱۰ دقیقه از خرابی گره، منابع به گره اصلی بازگردند:

pcs constraint location <resource_name> prefers <node_name>=INFINITY
pcs constraint location <resource_name> score=-INFINITY <node_name>

در اینجا، INFINITY مشخص می‌کند که منابع باید در گره اصلی باقی بمانند و پس از رفع خرابی گره، به‌طور خودکار به آن بازگردند.

مسیر فایل: این تنظیمات در /etc/pacemaker/pacemaker.conf ذخیره می‌شوند.

4. تنظیمات resource-stickiness برای جلوگیری از جابه‌جایی منابع در زمان Failover

اگر می‌خواهید منابع تمایل بیشتری به باقی‌ماندن در گره پشتیبان داشته باشند تا بعد از خرابی دوباره به گره اصلی بازگردند، می‌توانید از resource-stickiness استفاده کنید. این تنظیمات به‌طور دقیق‌تر سیاست‌های Failover و Failback را تنظیم می‌کند.

برای مثال، با استفاده از دستور زیر می‌توانید stickiness را به ۱۰ تنظیم کنید:

pcs resource meta <resource_name> resource-stickiness=10

در این حالت، منابع پس از Failover به گره دوم منتقل می‌شوند و پس از رفع خرابی گره اصلی، منابع به‌طور خودکار به آن گره باز می‌گردند.

مسیر فایل: این تنظیمات در /etc/pacemaker/pacemaker.conf ذخیره می‌شوند.

5. شبیه‌سازی Failover و Failback با تنظیمات زمانی

برای آزمایش این تنظیمات، می‌توانید از دستورات زیر برای شبیه‌سازی خرابی و بازگشت منابع به گره اصلی استفاده کنید:

1. ابتدا منابع را به گره پشتیبان انتقال دهید:

   pcs resource move <resource_name> <node_name>
   

2. سپس گره را به حالت خرابی درآورید:

   pcs node standby <node_name>
   

3. منابع باید پس از رفع خرابی به‌طور خودکار به گره اصلی بازگردند. برای اطمینان از این که این اتفاق می‌افتد، دستور زیر را وارد کنید:

   pcs resource move <resource_name> <node_name>
   

جمع‌بندی

در این بخش، تنظیمات مربوط به فواصل زمانی و شرایط زمانی برای مدیریت Failover و Failback بررسی شد. با استفاده از تنظیمات failure-timeout و migration-threshold، می‌توان فواصل زمانی را برای Failover تعیین کرد. برای Failback نیز از تنظیمات failback و failback-timeout استفاده می‌شود تا منابع پس از رفع خرابی به‌طور خودکار به گره اصلی بازگردند. همچنین با استفاده از resource-stickiness و location constraints می‌توان رفتار منابع را در مواجهه با خرابی‌ها به‌دقت تنظیم کرد. این تنظیمات به شما کمک می‌کنند تا اطمینان حاصل کنید که منابع به‌طور صحیح و در زمان مناسب به گره‌ها منتقل می‌شوند و پس از رفع خرابی به گره اصلی باز می‌گردند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 4. استفاده از Resource Sticks و Resource Fencing”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”مفهوم Resource Stickiness برای ماندن منابع در گره خاص” subtitle=”توضیحات کامل”]Resource Stickiness یکی از ویژگی‌های مهم در Pacemaker است که به شما این امکان را می‌دهد که رفتار منابع را در زمان انتقال بین گره‌ها کنترل کنید. این ویژگی به‌ویژه زمانی که می‌خواهید منابع در گره‌های خاصی باقی بمانند و از جابه‌جایی‌های غیرضروری جلوگیری شود، کاربرد دارد. با استفاده از تنظیمات stickiness می‌توان به‌طور مؤثری مشخص کرد که منابع چقدر تمایل دارند در گره‌ای خاص باقی بمانند و تحت چه شرایطی باید به گره دیگری منتقل شوند.

1. عملکرد Resource Stickiness

Resource Stickiness باعث می‌شود که منابع در گره‌های خاصی ثابت بمانند و در صورتی که یک گره دچار خرابی شود یا شرایط خاصی ایجاد شود، فقط در صورت نیاز واقعی به گره دیگری منتقل شوند. به عبارت دیگر، این ویژگی از جابه‌جایی‌های مکرر منابع جلوگیری کرده و به حفظ پایداری بیشتر منابع در گره‌ها کمک می‌کند.

وقتی یک منبع به گره‌ای اختصاص داده می‌شود، تنظیمات stickiness مشخص می‌کنند که منابع چقدر تمایل دارند در گره خود باقی بمانند و فقط در صورتی که گره سالم نباشد یا مشکلات جدی پیش بیاید، منابع به گره دیگر منتقل شوند. این تنظیمات به ویژه در کلاسترهایی که منابع زیادی دارند و انتقال مکرر آن‌ها می‌تواند باعث ایجاد تأخیر شود، بسیار مفید هستند.

2. نحوه پیکربندی Resource Stickiness

برای پیکربندی stickiness، از دستور زیر استفاده می‌شود:

pcs resource meta <resource_name> resource-stickiness=<value>

در این دستور:

• <resource_name> نام منبع مورد نظر است.
• <value> مقدار تمایل به باقی ماندن در گره خاص را تعیین می‌کند. هرچه این مقدار بیشتر باشد، منبع تمایل بیشتری به باقی ماندن در گره خواهد داشت.

مثال:

اگر بخواهید برای یک منبع خاص تمایل به باقی ماندن در گره را تنظیم کنید، دستور زیر را وارد می‌کنید:

pcs resource meta myResource resource-stickiness=10

در این مثال، myResource با مقدار stickiness برابر با ۱۰ تنظیم می‌شود، به این معنی که منابع تا حد امکان در گره فعلی باقی خواهند ماند و تنها در صورت خرابی گره، به گره دیگر منتقل می‌شوند.

مسیر فایل: این تنظیمات در /etc/pacemaker/pacemaker.conf ذخیره می‌شوند.

3. تنظیمات پیشرفته Resource Stickiness

برای کنترل دقیق‌تر بر نحوه انتقال منابع و جلوگیری از جابه‌جایی‌های غیرضروری، می‌توان از ترکیب resource-stickiness با location constraints استفاده کرد. این ترکیب به شما این امکان را می‌دهد که منابع را به گره خاصی اختصاص دهید و در صورت خرابی، فقط در صورت نیاز واقعی آن‌ها را به گره دیگر منتقل کنید.

دستور برای استفاده از location constraint همراه با stickiness:

pcs constraint location <resource_name> prefers <node_name>=INFINITY

این دستور باعث می‌شود که <resource_name> ترجیح دهد در گره <node_name> قرار بگیرد. مقدار INFINITY نشان می‌دهد که منابع باید به این گره اختصاص داده شوند و تنها در صورتی که گره خراب شود، به گره دیگری منتقل خواهند شد.

مثال:

اگر بخواهید منابع را ترجیحاً در گره node1 نگه دارید و به آن تمایل بیشتری دهید، دستور زیر را وارد می‌کنید:

pcs constraint location myResource prefers node1=INFINITY

این تنظیم باعث می‌شود که منبع myResource ترجیحاً در گره node1 قرار گیرد و در صورتی که این گره خراب شود، به گره دیگر منتقل خواهد شد.

مسیر فایل: این تنظیمات در /etc/pacemaker/pacemaker.conf ذخیره می‌شوند.

4. تأثیر Resource Stickiness بر Failover و Failback

Resource Stickiness به‌طور مستقیم بر نحوه Failover و Failback تأثیر می‌گذارد. زمانی که منبع به گره‌ای خاص اختصاص داده می‌شود و مقدار stickiness بالایی برای آن تنظیم می‌شود، این منبع به‌طور معمول در همان گره باقی می‌ماند تا زمانی که خرابی‌های جدی یا نیازهای خاص باعث انتقال آن به گره دیگر شود. بعد از رفع خرابی، منابع می‌توانند با سرعت به گره اصلی بازگردند و تنها در صورتی که نیاز به Failback باشد، انتقال انجام می‌شود.

پیکربندی Failback همراه با Stickiness:

برای فعال‌سازی Failback همراه با Stickiness، می‌توانید از دستور زیر استفاده کنید:

pcs resource meta myResource failback=true resource-stickiness=10

در این مثال، منبع myResource هم برای Failback تنظیم شده است و در صورتی که گره اصلی به‌طور موقت در دسترس نباشد، پس از رفع خرابی منابع به آن گره باز می‌گردند.

مسیر فایل: این تنظیمات در /etc/pacemaker/pacemaker.conf ذخیره می‌شوند.

5. بررسی وضعیت Stickiness

برای بررسی وضعیت تنظیمات stickiness و مشاهده منابع فعال و نحوه توزیع آن‌ها بین گره‌ها، می‌توانید از دستور زیر استفاده کنید:

pcs resource show <resource_name>

این دستور اطلاعات مربوط به myResource و وضعیت فعلی آن را نمایش می‌دهد، از جمله میزان stickiness و گره‌های اختصاص‌یافته به آن.

جمع‌بندی

مفهوم Resource Stickiness در کلاسترهای Pacemaker به شما این امکان را می‌دهد که منابع را در گره‌های خاصی ثابت نگه دارید و از جابه‌جایی‌های غیرضروری جلوگیری کنید. این تنظیمات با استفاده از resource-stickiness و location constraints قابل پیکربندی هستند و به شما کمک می‌کنند که منابع را به‌طور مؤثری در گره‌های سالم نگه دارید و تنها در صورت خرابی به گره‌های دیگر منتقل شوند. این ویژگی به‌ویژه در زمان‌های خرابی و بازگشت منابع (Failover و Failback) بسیار مفید است و پایداری منابع را در کلاسترهای HA تضمین می‌کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”پیکربندی Stickiness برای جلوگیری از انتقال منابع در هر بار Failover” subtitle=”توضیحات کامل”]در کلاسترهای HA (High Availability)، هدف از پیاده‌سازی ویژگی “Stickiness” یا “چسبندگی منابع” این است که منابع تنها در شرایط خاص (مانند خرابی گره) جابجا شوند و از جابه‌جایی مداوم منابع در هر Failover جلوگیری شود. این تنظیمات باعث می‌شود منابع به گره‌ای که در ابتدا به آن اختصاص داده شده‌اند، بچسبند و حتی بعد از خرابی به‌طور خودکار به همان گره برگردند، مگر اینکه خرابی‌ای جدید یا تغییرات دیگری رخ دهد.

در Pacemaker، با استفاده از پیکربندی Stickiness می‌توان این رفتار را تنظیم کرد تا منابع پس از Failover به گره‌ای که اولین بار بر روی آن اجرا شده‌اند، بازگردند.

نحوه پیکربندی Stickiness

برای پیکربندی Stickiness، شما باید از پارامتر resource-stickiness استفاده کنید. این پارامتر میزان چسبندگی (Stickiness) یک منبع را تعیین می‌کند.

به‌طور کلی، با استفاده از دستور pcs resource meta می‌توان این پارامتر را تنظیم کرد. این پارامتر عددی است که نشان‌دهنده میزان تمایل Pacemaker برای نگه‌داشتن منابع روی یک گره خاص است.

مراحل پیکربندی Stickiness

1. ابتدا باید به گره‌ای که می‌خواهید منابع آن چسبنده باشند، وارد شوید.
2. سپس از دستور pcs resource meta برای پیکربندی Stickiness استفاده کنید.

مثال:

فرض کنید یک سرویس به نام my_service دارید و می‌خواهید این سرویس به مدت 1000 ثانیه روی گره‌ای که اول قرار دارد، باقی بماند.

1. برای پیکربندی Stickiness برای منابع، از دستور زیر استفاده کنید:

pcs resource meta my_service resource-stickiness=1000

در این مثال:

• my_service نام منبع یا سرویس است.
• resource-stickiness=1000 به معنی تنظیم چسبندگی به 1000 واحد است.

2. پس از تنظیم این مقدار، حتی اگر گره‌ای دچار خرابی شود و Failover رخ دهد، منابع تلاش خواهند کرد تا دوباره به همان گره اصلی بازگردند (مگر در صورت نیاز به جابجایی مجدد).

مسیر فایل پیکربندی:

برای ذخیره تنظیمات در فایل‌های پیکربندی، این تغییرات معمولاً در فایل‌های زیر ذخیره می‌شوند:

• /etc/corosync/corosync.conf (برای تنظیمات Corosync)
• /etc/pacemaker/pacemaker.conf (برای تنظیمات Pacemaker)

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

جمع بندی

پیکربندی Stickiness در Pacemaker به شما این امکان را می‌دهد که منابع را به گره خاصی اختصاص داده و از جابه‌جایی آن‌ها در طول Failover جلوگیری کنید. با استفاده از پارامتر resource-stickiness می‌توان میزان تمایل منابع به نگهداری در یک گره خاص را مشخص کرد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تعریف و پیکربندی Resource Fencing به منظور جلوگیری از مشکلات ناشی از درگیری منابع در گره‌های مختلف” subtitle=”توضیحات کامل”]Resource Fencing یک مکانیزم مهم در کلاسترهای HA (High Availability) است که برای جلوگیری از مشکلات ناشی از درگیری منابع (Resource Contention) در گره‌های مختلف طراحی شده است. این قابلیت تضمین می‌کند که منابع حساس و حیاتی فقط توسط یک گره در هر زمان استفاده شوند، که مانع از بروز مشکلاتی مانند دو گره که به طور هم‌زمان به یک منبع دسترسی دارند، می‌شود. در صورتی که یکی از گره‌ها دچار خرابی یا تداخل شود، Fencing به طور خودکار گره‌ی مشکل‌دار را از کلاستر حذف می‌کند و دسترسی به منابع را محدود می‌کند.

Fencing درواقع فرآیندی است که به گره‌ها این امکان را می‌دهد که منابع خود را ایزوله کنند و در صورتی که یکی از گره‌ها به‌طور اشتباه به منابع دسترسی پیدا کرد، آن را به‌طور ایمن از دسترسی خارج کنند.

نحوه پیکربندی Resource Fencing در Pacemaker

در Pacemaker، پیکربندی Fencing معمولاً از طریق استفاده از منابع فنس (Fence) انجام می‌شود. این منابع فنس مسئول قطع یا “فنس‌گذاری” گره‌ها هستند تا از درگیری‌های منابع جلوگیری کنند.

مراحل پیکربندی Resource Fencing:

1. تعریف نوع Fencing برای گره‌ها:

   برای پیکربندی Fencing، اولین قدم انتخاب یک ابزار Fencing است. در اینجا، از منابع fence که به طور پیش‌فرض در Pacemaker پشتیبانی می‌شود، استفاده می‌کنیم. ابزارهای مختلفی برای Fencing وجود دارند، مانند fence_ipmilan, fence_scsihw, یا fence_virsh که باید مطابق با نوع سخت‌افزار یا ماشین مجازی مورد استفاده شما انتخاب شوند.

2. ایجاد منابع Fencing:

   برای ایجاد یک منبع فنس و اعمال آن به گره‌ها، می‌توانید از دستور pcs استفاده کنید.

مثال:

فرض کنید می‌خواهید از فنس fence_ipmilan برای حفاظت از گره‌ها استفاده کنید. این ابزار از IPMI برای مدیریت سرورهای فیزیکی استفاده می‌کند.

pcs resource create fence1 fence_ipmilan pcmk_host_list="node1,node2" ipaddr="192.168.0.100" login="admin" passwd="password" op monitor interval="30s" timeout="10s"

در این مثال:

• fence_ipmilan: نوع فنس انتخابی است.
• pcmk_host_list="node1,node2": فهرستی از گره‌هایی که باید به فنس اضافه شوند.
• ipaddr="192.168.0.100": IP آدرس برای دسترسی به سرور مدیریت.
• login="admin" و passwd="password": اطلاعات ورود به سیستم مدیریت IPMI.
• op monitor interval="30s" timeout="10s": تنظیمات نظارت و زمان‌بندی برای بررسی وضعیت گره‌ها.

3. فعال‌سازی فنس بر روی گره‌ها:

   بعد از ایجاد منبع فنس، می‌توانید آن را برای هر گره فعال کنید.

pcs resource enable fence1

4. مقداردهی به اولویت Fencing:

   برای تنظیم اولویت‌ها در پیکربندی Fencing، می‌توانید از دستور pcs resource meta استفاده کنید.

pcs resource meta fence1 target-role="Started" priority="100"

در این مثال:

• target-role="Started" به این معنی است که فنس‌ها به محض شروع به کار گره‌ها باید فعال شوند.
• priority="100" اولویت فنس را مشخص می‌کند.

مسیر فایل پیکربندی:

فایل‌های پیکربندی برای تنظیمات Fencing معمولاً در این مسیرها ذخیره می‌شوند:

• /etc/corosync/corosync.conf (برای تنظیمات Corosync)
• /etc/pacemaker/pacemaker.conf (برای تنظیمات Pacemaker)
• /etc/cluster/fence.conf (برای تنظیمات فنس خاص)

جمع بندی

Resource Fencing ابزاری حیاتی در کلاسترهای HA است که از درگیری منابع در گره‌های مختلف جلوگیری می‌کند. با استفاده از منابع فنس در Pacemaker، می‌توانید تضمین کنید که هر گره فقط به منابع مورد نظر خود دسترسی داشته باشد و در صورت بروز خرابی یا تداخل، منابع به‌طور ایمن از گره‌های خراب جدا شوند. این تنظیمات به‌طور معمول از طریق ابزارهایی مانند fence_ipmilan و دستوراتی مانند pcs resource create و pcs resource meta انجام می‌شوند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از STONITH (Shoot The Other Node in The Head) برای فعال‌سازی Fencing و جلوگیری از مشکلات دسترسی به منابع” subtitle=”توضیحات کامل”]STONITH (Shoot The Other Node in The Head) یک تکنیک حیاتی برای جلوگیری از مشکلات دسترسی به منابع در کلاسترهای High Availability (HA) است. این روش با استفاده از یک مکانیزم فنس‌گذاری (fencing)، گره‌های مشکل‌دار را به‌طور مؤثر از کلاستر جدا می‌کند و تضمین می‌کند که هیچ گره‌ای به منابع مشترک دسترسی غیرمجاز نداشته باشد.

در حالت عادی، اگر یک گره در کلاستر دچار خرابی شود، ممکن است به منابع مشترک مانند IP‌ها، فایل‌سیستم‌ها و سرویس‌ها دسترسی داشته باشد، که می‌تواند منجر به درگیری‌های منابع و مشکلات جدی شود. برای جلوگیری از این موضوع، از تکنیک STONITH استفاده می‌شود که با قطع دسترسی به گره‌های مشکل‌دار (از طریق راه‌هایی مثل خاموش کردن گره یا قطع ارتباط شبکه)، از این نوع خرابی‌ها جلوگیری می‌کند.

نحوه استفاده از STONITH در Pacemaker

در Pacemaker، می‌توان از ابزارهای مختلف Fencing برای فعال‌سازی STONITH استفاده کرد. این ابزارها معمولاً به روش‌های مختلف مانند IPMI, iLO, DRAC, SSH, یا ابزارهای مشابه برای خاموش کردن گره‌های خراب یا غیرقابل دسترسی استفاده می‌شوند.

مراحل پیکربندی STONITH:

1. انتخاب ابزار STONITH:

   اولین قدم برای استفاده از STONITH، انتخاب ابزار مناسب برای فنس‌گذاری گره‌ها است. به‌طور معمول، ابزارهایی مانند fence_ipmilan، fence_virsh، و fence_ilo برای سرورهای فیزیکی و مجازی به‌کار می‌روند. این ابزارها می‌توانند از طریق پروتکل‌هایی مانند IPMI یا SSH برای قطع دسترسی به گره‌های مشکل‌دار استفاده کنند.

2. پیکربندی منبع STONITH:

   برای پیکربندی STONITH، از دستور pcs resource create استفاده می‌شود تا منبع STONITH ایجاد شود. در این مرحله باید ابزار فنس‌گذاری و تنظیمات مربوط به آن را مشخص کنید.

مثال: پیکربندی fence_ipmilan برای استفاده از STONITH

در این مثال، از ابزار fence_ipmilan استفاده خواهیم کرد تا دسترسی به گره‌ها را با استفاده از IPMI مدیریت کنیم.

pcs resource create stonith-fence fence_ipmilan pcmk_host_list="node1,node2" ipaddr="192.168.0.100" login="admin" passwd="password" op monitor interval="30s" timeout="10s"

در این مثال:

• fence_ipmilan: ابزار STONITH انتخابی است.
• pcmk_host_list="node1,node2": فهرست گره‌هایی که باید به فنس‌گذاری اضافه شوند.
• ipaddr="192.168.0.100": آدرس IP سرور مدیریت که به IPMI دسترسی دارد.
• login="admin" و passwd="password": نام کاربری و رمز عبور برای ورود به سیستم مدیریت IPMI.
• op monitor interval="30s" timeout="10s": تنظیمات نظارت و زمان‌بندی برای بررسی وضعیت گره‌ها.

3. فعال‌سازی منابع STONITH:

   پس از ایجاد منبع STONITH، آن را باید برای گره‌ها فعال کنید. این عمل را با استفاده از دستور pcs resource enable انجام می‌دهید:

pcs resource enable stonith-fence

این دستور منبع STONITH را فعال کرده و باعث می‌شود که گره‌های مشکل‌دار به‌طور خودکار فنس‌گذاری شوند.

4. پیکربندی متا-داده‌ها برای STONITH:

   برای اطمینان از اولویت‌بندی و رفتار صحیح STONITH، از دستور pcs resource meta برای تنظیم ویژگی‌های اضافی مانند اولویت فنس‌گذاری استفاده می‌شود.

pcs resource meta stonith-fence target-role="Started" priority="100"

در اینجا:

• target-role="Started": این پارامتر تضمین می‌کند که STONITH برای گره‌هایی که در حالت “Started” هستند، فعال می‌شود.
• priority="100": اولویت این منبع را مشخص می‌کند که در صورت نیاز به اجرای فنس‌گذاری، این منبع به‌طور خودکار وارد عمل شود.

5. پیکربندی فنس‌گذاری برای تمامی گره‌ها:

   برای اطمینان از اینکه STONITH در تمام گره‌های کلاستر فعال است، باید به هر گره یک منبع STONITH اختصاص داده شود. این کار را می‌توان با اجرای دستور مشابه برای گره‌های دیگر انجام داد:

pcs resource create stonith-fence2 fence_ipmilan pcmk_host_list="node3,node4" ipaddr="192.168.0.101" login="admin" passwd="password" op monitor interval="30s" timeout="10s"

مسیر فایل پیکربندی:

فایل‌های پیکربندی STONITH معمولاً در این مسیرها قرار دارند:

• /etc/corosync/corosync.conf (برای تنظیمات Corosync)
• /etc/pacemaker/pacemaker.conf (برای تنظیمات Pacemaker)
• /etc/cluster/fence.conf (برای تنظیمات فنس‌گذاری)

جمع بندی

STONITH ابزاری ضروری برای کلاسترهای HA است که با استفاده از فنس‌گذاری، از درگیری منابع در گره‌های مختلف جلوگیری می‌کند. با فعال‌سازی STONITH، اگر یکی از گره‌ها دچار خرابی شود، دسترسی به منابع حساس و حیاتی آن گره قطع شده و از بروز مشکلات بیشتر جلوگیری می‌شود. پیکربندی STONITH با استفاده از ابزارهای مختلف مانند fence_ipmilan و دستورات pcs resource create و pcs resource enable انجام می‌شود. این تنظیمات به شما کمک می‌کنند تا به‌طور خودکار و مؤثر گره‌های مشکل‌دار را از کلاستر خارج کنید و از دسترسی غیرمجاز به منابع جلوگیری کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 5. پشتیبانی از انواع مختلف منابع”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”پشتیبانی از منابع شبکه‌ای مانند IP و Load Balancers” subtitle=”توضیحات کامل”]در یک کلاستر HA، مدیریت منابع شبکه‌ای مانند IPها و Load Balancer‌ها برای توزیع صحیح بار و اطمینان از در دسترس بودن سرویس‌ها در صورت خرابی گره‌ها بسیار مهم است. برای پشتیبانی از این منابع، از Pacemaker و Corosync استفاده می‌شود که می‌توانند منابع شبکه‌ای مانند IP‌های مجازی، سرویس‌های DNS، و تنظیمات Load Balancer‌ها را مدیریت کرده و در صورت خرابی یکی از گره‌ها، این منابع را به گره سالم انتقال دهند.

1. پیکربندی IP‌های مجازی

یکی از مهم‌ترین منابع شبکه‌ای که در کلاسترهای HA باید مدیریت شود، IPهای مجازی هستند. این IPها به‌طور معمول در هر گره قرار دارند و در صورت خرابی گره، به گره سالم منتقل می‌شوند. برای این کار از دستور pcs resource create برای ایجاد منابع IP استفاده می‌کنیم.

مثال: پیکربندی یک IP مجازی

برای پیکربندی یک IP مجازی که در هر گره در دسترس باشد، از دستور زیر استفاده می‌کنیم:

pcs resource create VirtualIP IPaddr2 ip="192.168.0.100" cidr_netmask="24" op monitor interval="30s" timeout="10s"

در این دستور:

• VirtualIP: نام منبع است که می‌توان آن را به هر نام دلخواه تغییر داد.
• IPaddr2: نوع منبع است که به IP مجازی اشاره دارد.
• ip="192.168.0.100": آدرس IP که باید در کلاستر استفاده شود.
• cidr_netmask="24": ماسک شبکه IP.
• op monitor interval="30s" timeout="10s": تنظیمات نظارت برای IP مجازی.

این دستور به صورت خودکار یک IP مجازی برای کلاستر تعریف می‌کند و آن را برای بررسی وضعیت و انتقال به گره سالم تنظیم می‌کند.

مسیر فایل پیکربندی:

• فایل‌های پیکربندی منابع شبکه‌ای در مسیر /etc/pacemaker/pacemaker.conf و /etc/corosync/corosync.conf قرار می‌گیرند.

2. پیکربندی Load Balancer

برای پشتیبانی از Load Balancer‌ها در کلاسترهای HA، به‌طور معمول از منابعی مانند HAProxy یا Keepalived برای توزیع بار بین گره‌ها استفاده می‌شود. این منابع باید طوری پیکربندی شوند که در صورت خرابی یکی از گره‌ها، درخواست‌ها به گره سالم هدایت شوند.

برای پیکربندی Load Balancer در Pacemaker، از دستور pcs resource create برای ایجاد منابع مربوط به Load Balancer استفاده می‌شود.

مثال: پیکربندی HAProxy برای توزیع بار

در اینجا یک مثال برای پیکربندی HAProxy به‌عنوان یک Load Balancer برای توزیع درخواست‌ها به گره‌های مختلف کلاستر آورده شده است:

pcs resource create LoadBalancer ldirectord config="/etc/ldirectord.conf" op monitor interval="30s" timeout="10s"

در این دستور:

• LoadBalancer: نام منبع است.
• ldirectord: نوع منبع است که به HAProxy اشاره دارد.
• config="/etc/ldirectord.conf": مسیر فایل پیکربندی HAProxy که شامل تنظیمات توزیع بار است.
• op monitor interval="30s" timeout="10s": تنظیمات نظارت برای Load Balancer.

در این حالت، HAProxy به‌عنوان Load Balancer عمل کرده و درخواست‌ها را به گره‌های سالم کلاستر هدایت می‌کند.

مسیر فایل پیکربندی:

• فایل پیکربندی HAProxy در مسیر /etc/ldirectord.conf قرار دارد.

3. پیکربندی فیلترها و قواعد برای منابع شبکه‌ای

برای اطمینان از توزیع صحیح بار و جلوگیری از مشکلات اتصال، می‌توان از فیلترها و قواعد خاصی استفاده کرد. به‌عنوان مثال، می‌توان فیلترهایی برای تعیین اولویت‌های انتقال منابع ایجاد کرد.

مثال: پیکربندی فیلتر برای IP مجازی

در اینجا، یک فیلتر برای تعیین اولویت‌های انتقال IP مجازی به گره سالم آورده شده است:

pcs resource meta VirtualIP priority="100" clone-max="2" clone-node-max="1"

در این دستور:

• priority="100": اولویت این منبع را مشخص می‌کند که در صورت خرابی گره، انتقال به گره دیگر با این اولویت صورت گیرد.
• clone-max="2": تعداد کپی‌های مجاز از این منبع.
• clone-node-max="1": تعداد کپی‌های مجاز در هر گره.

مسیر فایل پیکربندی:

• فایل‌های پیکربندی مربوط به این فیلترها معمولاً در فایل‌های pacemaker.conf قرار دارند.

جمع بندی

برای پشتیبانی از منابع شبکه‌ای مانند IP‌ها و Load Balancer‌ها در کلاسترهای HA، از ابزارهایی مانند Pacemaker و Corosync استفاده می‌شود. پیکربندی این منابع از طریق دستورات pcs resource create انجام می‌شود، که در آن منابع مختلف مانند IP مجازی و HAProxy برای توزیع بار تنظیم می‌شوند. همچنین، از فیلترها و قواعد خاصی برای تعیین اولویت‌ها و جلوگیری از مشکلات دسترسی به منابع استفاده می‌شود. این تنظیمات باعث می‌شوند که منابع شبکه‌ای به‌طور خودکار و مؤثر در کلاستر منتقل شده و درخواست‌ها به گره‌های سالم هدایت شوند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”پشتیبانی از منابع ذخیره‌سازی شامل iSCSI، NFS، و SAN” subtitle=”توضیحات کامل”]در کلاسترهای HA (High Availability)، پشتیبانی و مدیریت منابع ذخیره‌سازی برای اطمینان از در دسترس بودن داده‌ها و برنامه‌ها در هر شرایطی حیاتی است. در این زمینه، از انواع مختلف منابع ذخیره‌سازی مانند iSCSI، NFS، و SAN استفاده می‌شود که باید به‌درستی پیکربندی شوند تا در صورت خرابی یکی از گره‌ها، منابع ذخیره‌سازی به گره سالم منتقل شوند.

1. پیکربندی iSCSI

iSCSI (Internet Small Computer Systems Interface) یک پروتکل ذخیره‌سازی است که از TCP/IP برای اتصال به ذخیره‌سازی‌های راه دور استفاده می‌کند. در یک کلاستر HA، معمولاً از iSCSI برای اتصال گره‌ها به یک ذخیره‌سازی مشترک استفاده می‌شود.

مراحل پیکربندی iSCSI در کلاستر

1. نصب بسته‌های موردنیاز:

ابتدا باید بسته‌های لازم برای پشتیبانی از iSCSI را نصب کنید. این بسته‌ها معمولاً به‌صورت زیر نصب می‌شوند:

yum install iscsi-initiator-utils

2. اتصال به ذخیره‌سازی iSCSI:

برای اتصال به ذخیره‌سازی iSCSI، از دستور زیر استفاده می‌کنیم:

iscsiadm --mode discovery --type sendtargets --portal <IP-Address-of-iSCSI-Target>
iscsiadm --mode node --targetname <Target-Name> --login

در اینجا:

• <IP-Address-of-iSCSI-Target>: آدرس IP مقصد iSCSI است.
• <Target-Name>: نام هدف iSCSI است.

3. پیکربندی منابع iSCSI در Pacemaker:

پس از اتصال گره‌ها به ذخیره‌سازی iSCSI، باید آن را به‌عنوان یک منبع در Pacemaker پیکربندی کنیم. برای این کار، از دستور pcs resource create استفاده می‌کنیم:

pcs resource create iSCSI-Target ocf:heartbeat:iscsi target="iqn.2025-03.com.example:target" portal="192.168.1.100" op monitor interval="30s"

در این دستور:

• iSCSI-Target: نام منبع است.
• ocf:heartbeat:iscsi: نوع منبع است که به iSCSI اشاره دارد.
• target="iqn.2025-03.com.example:target": شناسه هدف iSCSI است.
• portal="192.168.1.100": آدرس IP مقصد iSCSI است.
• op monitor interval="30s": تنظیمات نظارت برای این منبع.

مسیر فایل پیکربندی:

• فایل‌های پیکربندی مربوط به منابع iSCSI در /etc/pacemaker/pacemaker.conf قرار دارند.

2. پیکربندی NFS

NFS (Network File System) پروتکلی است که به کاربران اجازه می‌دهد تا به فایل‌های ذخیره‌شده بر روی سرورهای دیگر دسترسی پیدا کنند. NFS برای اشتراک‌گذاری فایل‌ها در یک شبکه محلی استفاده می‌شود و در کلاسترهای HA برای دسترسی مشترک به فایل‌ها استفاده می‌شود.

مراحل پیکربندی NFS در کلاستر

1. نصب بسته‌های NFS:

ابتدا باید بسته‌های NFS را نصب کنید:

yum install nfs-utils

2. پیکربندی منابع NFS در Pacemaker:

برای پیکربندی NFS به‌عنوان یک منبع در Pacemaker، ابتدا باید منبع NFS را به‌صورت زیر ایجاد کنیم:

pcs resource create NFS-Share Filesystem nfs file_system="/mnt/nfs" device="192.168.1.50:/export/nfs" fstype="nfs" op monitor interval="30s"

در این دستور:

• NFS-Share: نام منبع است.
• Filesystem nfs: نوع منبع است که به NFS اشاره دارد.
• file_system="/mnt/nfs": مسیر نقطه مونت (mount) بر روی گره‌های کلاستر است.
• device="192.168.1.50:/export/nfs": مسیر به منابع NFS که در سرور مقصد در دسترس است.
• fstype="nfs": نوع فایل‌سیستم NFS.
• op monitor interval="30s": تنظیمات نظارت برای NFS.

مسیر فایل پیکربندی:

• فایل‌های پیکربندی مربوط به منابع NFS در /etc/pacemaker/pacemaker.conf قرار دارند.

3. پیکربندی SAN

SAN (Storage Area Network) یک شبکه اختصاصی برای ذخیره‌سازی است که از پروتکل‌های مختلف مانند iSCSI، Fibre Channel و FCoE برای اتصال به ذخیره‌سازی‌های مرکزی استفاده می‌کند. برای استفاده از SAN در کلاسترهای HA، ابتدا باید یک ذخیره‌سازی مشترک در دسترس گره‌ها قرار گیرد و سپس در Pacemaker برای دسترسی و انتقال منابع پیکربندی شود.

مراحل پیکربندی SAN در کلاستر

1. اتصال به ذخیره‌سازی SAN:

برای اتصال گره‌ها به ذخیره‌سازی SAN، ابتدا باید پروتکل مورد استفاده برای اتصال (مانند Fibre Channel یا iSCSI) را تنظیم کنید.

2. پیکربندی منابع SAN در Pacemaker:

برای پیکربندی منابع SAN در Pacemaker، از دستور زیر استفاده می‌کنیم:

pcs resource create SAN-Storage LVM volume_group="vg01" logical_volume="lv_data" op monitor interval="30s"

در این دستور:

• SAN-Storage: نام منبع است.
• LVM: نوع منبع است که به LVM اشاره دارد.
• volume_group="vg01": نام گروه حجمی است.
• logical_volume="lv_data": نام حجم منطقی است.
• op monitor interval="30s": تنظیمات نظارت برای SAN.

مسیر فایل پیکربندی:

• فایل‌های پیکربندی مربوط به منابع SAN در /etc/pacemaker/pacemaker.conf قرار دارند.

جمع بندی

پشتیبانی از منابع ذخیره‌سازی مانند iSCSI، NFS، و SAN در کلاسترهای HA از اهمیت زیادی برخوردار است تا داده‌ها و سرویس‌ها در صورت خرابی گره‌ها یا مشکلات شبکه در دسترس باقی بمانند. برای پیکربندی این منابع در کلاستر، از Pacemaker استفاده می‌شود که به‌طور خودکار منابع ذخیره‌سازی را در گره‌های مختلف منتقل می‌کند. تنظیمات این منابع ذخیره‌سازی با استفاده از دستورات pcs resource create انجام می‌شود و پیکربندی فایل‌های مربوطه در مسیر /etc/pacemaker/pacemaker.conf قرار دارد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”پشتیبانی از منابع نرم‌افزاری مانند دیتابیس‌ها (مثلاً MySQL) و برنامه‌ها” subtitle=”توضیحات کامل”]در کلاسترهای HA (High Availability)، پشتیبانی از منابع نرم‌افزاری مانند دیتابیس‌ها و برنامه‌ها حیاتی است، زیرا در صورت خرابی یک گره یا سرویس، لازم است که این منابع به‌طور خودکار به گره سالم منتقل شوند تا از عدم دسترسی به سرویس‌ها و داده‌ها جلوگیری شود. برای پشتیبانی از منابع نرم‌افزاری مانند دیتابیس‌ها (مثلاً MySQL) و برنامه‌ها، باید منابع نرم‌افزاری را به‌طور صحیح پیکربندی کرده و برای انتقال خودکار در صورت خرابی گره‌ها یا سرویس‌ها، تنظیمات مربوطه را انجام داد.

1. پیکربندی MySQL در کلاستر HA

MySQL یکی از محبوب‌ترین سیستم‌های مدیریت پایگاه‌داده است که در کلاسترهای HA برای ذخیره و مدیریت داده‌ها استفاده می‌شود. برای پشتیبانی از MySQL در کلاسترهای HA، از Pacemaker استفاده می‌شود که به‌طور خودکار MySQL را در صورت خرابی گره، به گره سالم منتقل می‌کند.

مراحل پیکربندی MySQL در کلاستر

1. نصب و پیکربندی MySQL:

ابتدا باید MySQL را بر روی گره‌های کلاستر نصب کنید:

yum install mysql-server
systemctl enable mysqld
systemctl start mysqld

پس از نصب و راه‌اندازی MySQL، باید اطمینان حاصل کنید که MySQL به‌درستی بر روی تمام گره‌ها پیکربندی شده و آماده استفاده است.

2. پیکربندی MySQL برای کلاستر:

برای پیکربندی MySQL به‌عنوان یک منبع در Pacemaker، از دستورات زیر استفاده می‌کنیم. ابتدا باید مطمئن شویم که MySQL به‌صورت سرویس‌ها یا منابعی در کلاستر در دسترس است.

pcs resource create MySQL ocf:heartbeat:mysql config="/etc/my.cnf" op monitor interval="30s"

در این دستور:

• MySQL: نام منبع است.
• ocf:heartbeat:mysql: نوع منبع است که به MySQL اشاره دارد.
• config="/etc/my.cnf": مسیر فایل پیکربندی MySQL است.
• op monitor interval="30s": تنظیمات نظارت برای MySQL.

3. پیکربندی IP مجازی برای MySQL:

برای دسترسی به MySQL از یک IP مجازی استفاده می‌شود که در صورت خرابی گره، به گره سالم منتقل شود. این IP می‌تواند به‌عنوان نقطه دسترسی به پایگاه‌داده MySQL در نظر گرفته شود.

pcs resource create MySQL-VIP IPaddr2 ip="192.168.1.100" cidr_netmask="24" op monitor interval="30s"

در این دستور:

• MySQL-VIP: نام منبع است.
• IPaddr2: نوع منبع است که به IP مجازی اشاره دارد.
• ip="192.168.1.100": آدرس IP مجازی است.
• cidr_netmask="24": ماسک شبکه برای IP مجازی.
• op monitor interval="30s": تنظیمات نظارت برای IP مجازی.

مسیر فایل پیکربندی:

• فایل‌های پیکربندی مربوط به منابع MySQL در /etc/pacemaker/pacemaker.conf قرار دارند.

2. پیکربندی منابع نرم‌افزاری دیگر (برنامه‌ها)

در کنار دیتابیس‌ها، کلاسترهای HA معمولاً برای پشتیبانی از برنامه‌ها نیز به کار می‌روند. این برنامه‌ها ممکن است شامل وب‌سرویس‌ها، اپلیکیشن‌های سازمانی، یا سایر نرم‌افزارهای حساس به در دسترس بودن باشند که باید در کلاستر پیکربندی شوند.

مراحل پیکربندی برنامه‌ها در کلاستر

1. پیکربندی سرویس‌ها:

برای پیکربندی یک سرویس نرم‌افزاری (مانند وب‌سرویس‌ها یا برنامه‌های دیگر) به‌عنوان منبع در Pacemaker، از دستورات زیر استفاده می‌کنیم:

pcs resource create WebApp apache configfile="/etc/httpd/conf/httpd.conf" op monitor interval="30s"

در این دستور:

• WebApp: نام منبع است.
• apache: نوع منبع است که به Apache Web Server اشاره دارد.
• configfile="/etc/httpd/conf/httpd.conf": مسیر فایل پیکربندی Apache است.
• op monitor interval="30s": تنظیمات نظارت برای وب‌سرویس.

2. پیکربندی IP مجازی برای سرویس‌ها:

برای این‌که برنامه‌ها نیز از یک IP مجازی استفاده کنند که در صورت خرابی گره، به گره سالم منتقل شود، دستور زیر را استفاده می‌کنیم:

pcs resource create WebApp-VIP IPaddr2 ip="192.168.1.101" cidr_netmask="24" op monitor interval="30s"

در این دستور:

• WebApp-VIP: نام منبع است.
• IPaddr2: نوع منبع است که به IP مجازی اشاره دارد.
• ip="192.168.1.101": آدرس IP مجازی است.
• cidr_netmask="24": ماسک شبکه برای IP مجازی.
• op monitor interval="30s": تنظیمات نظارت برای IP مجازی.

مسیر فایل پیکربندی:

• فایل‌های پیکربندی مربوط به منابع نرم‌افزاری دیگر مانند برنامه‌ها در /etc/pacemaker/pacemaker.conf قرار دارند.

جمع بندی

پشتیبانی از منابع نرم‌افزاری مانند MySQL و برنامه‌ها در کلاسترهای HA برای حفظ دسترسی به داده‌ها و سرویس‌ها در صورت خرابی گره‌ها یا سرویس‌ها بسیار اهمیت دارد. این منابع به‌طور خودکار با استفاده از Pacemaker پیکربندی شده و در صورت خرابی گره یا سرویس، به گره سالم منتقل می‌شوند. تنظیمات مربوط به MySQL و برنامه‌ها در فایل‌های پیکربندی Pacemaker ذخیره می‌شوند که معمولاً در مسیر /etc/pacemaker/pacemaker.conf قرار دارند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 6. بررسی و تجزیه‌وتحلیل وضعیت منابع”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”بررسی وضعیت منابع در کلاستر با استفاده از دستورات crm status و pcs status” subtitle=”توضیحات کامل”]در کلاسترهای HA، برای مدیریت و نظارت بر وضعیت منابع و گره‌ها، از ابزارهای مختلفی استفاده می‌شود. دو ابزار پرکاربرد در این زمینه crm و pcs هستند که هرکدام دستورات خاص خود را برای بررسی وضعیت کلاستر و منابع ارائه می‌دهند. در این بخش، به بررسی نحوه استفاده از دستورات crm status و pcs status برای بررسی وضعیت منابع در کلاسترهای HA خواهیم پرداخت.

1. بررسی وضعیت کلاستر با دستور crm status

دستور crm status یکی از دستورات اصلی برای بررسی وضعیت کلاستر است. این دستور اطلاعات کاملی در مورد وضعیت گره‌ها، منابع، و سیاست‌های کلاستر در اختیار کاربران قرار می‌دهد. با استفاده از این دستور می‌توان وضعیت فعال بودن یا غیرفعال بودن منابع و گره‌ها را مشاهده کرد و از جزئیات مربوط به عملیات Failover و Failback آگاه شد.

نحوه استفاده از دستور crm status

برای استفاده از دستور crm status، کافیست دستور زیر را وارد کنید:

crm status

این دستور اطلاعات زیر را نمایش می‌دهد:

• وضعیت کلی کلاستر (فعال یا غیرفعال)
• لیست گره‌ها و وضعیت هر کدام (فعال یا غیرفعال)
• وضعیت منابع (آیا در حال اجرا هستند یا متوقف شده‌اند)
• اطلاعات مربوط به انتقال منابع بین گره‌ها
• وضعیت پیکربندی و تنظیمات کلاستر

مثال خروجی دستور crm status:

Cluster Status:
 Last updated: Fri Mar  9 14:53:11 2025
 Stack: corosync
 Current DC: node-01 (version 1.1.2-1)
 2 nodes and 3 resources configured

 Node node-01: online
 Node node-02: online

 Resource Group: mysql-group
     mysql        (ocf::heartbeat:mysql): Started node-01
     mysql-vip    (ocf::heartbeat:IPaddr2): Started node-01

در این مثال:

• دو گره به نام‌های node-01 و node-02 به‌صورت آنلاین هستند.
• منابع mysql و mysql-vip در گره node-01 در حال اجرا هستند.
• اطلاعات مربوط به وضعیت هر منبع و گره در این دستور قابل مشاهده است.

2. بررسی وضعیت کلاستر با دستور pcs status

دستور pcs status یک ابزار مشابه crm status است، اما برای محیط‌های کلاستری که از Pacemaker و Corosync استفاده می‌کنند، کاربرد بیشتری دارد. دستور pcs status نیز وضعیت کلی کلاستر، گره‌ها و منابع را نمایش می‌دهد و جزئیات بیشتری در مورد نحوه پیکربندی کلاستر را ارائه می‌کند.

نحوه استفاده از دستور pcs status

برای استفاده از دستور pcs status، دستور زیر را وارد کنید:

pcs status

این دستور به‌طور مشابه دستور crm status وضعیت گره‌ها، منابع و پیکربندی کلاستر را نمایش می‌دهد، با این تفاوت که ممکن است برخی جزئیات بیشتر در این دستور موجود باشد.

مثال خروجی دستور pcs status:

Cluster Status:
 Last updated: Fri Mar  9 14:53:11 2025
 Stack: corosync
 Current DC: node-01 (version 1.1.2-1)
 2 nodes and 3 resources configured

 Node node-01: online
 Node node-02: online

 Resource Group: mysql-group
     mysql        (ocf::heartbeat:mysql): Started node-01
     mysql-vip    (ocf::heartbeat:IPaddr2): Started node-01

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

مقایسه بین دستورات crm status و pcs status

• هر دو دستور، وضعیت کلی کلاستر، گره‌ها و منابع را نمایش می‌دهند.
• دستور crm status برای کار با Corosync و Pacemaker به‌طور عمومی استفاده می‌شود.
• دستور pcs status معمولاً در کلاسترهایی که از Pacemaker به‌طور خاص استفاده می‌کنند، کاربرد دارد.
• pcs status ممکن است گزینه‌های بیشتری برای پیکربندی و تغییرات در کلاستر نسبت به crm status داشته باشد.

مسیر فایل پیکربندی:

• فایل‌های پیکربندی مربوط به منابع کلاستر در /etc/pacemaker/pacemaker.conf قرار دارند.

جمع بندی

برای بررسی وضعیت منابع در کلاسترهای HA می‌توان از دستورات crm status و pcs status استفاده کرد. هر دو دستور اطلاعات دقیقی در مورد وضعیت گره‌ها، منابع و پیکربندی‌های کلاستر ارائه می‌دهند. این دستورات به مدیران سیستم کمک می‌کنند تا وضعیت منابع را بررسی کرده و در صورت بروز مشکلات، اقدامات لازم را انجام دهند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تجزیه‌وتحلیل وضعیت منابع در هنگام Failover و Failback” subtitle=”توضیحات کامل”]در کلاسترهای HA (High Availability)، زمانی که یک گره یا منبع با مشکل مواجه می‌شود، فرآیند Failover و Failback برای انتقال منابع به گره‌های سالم و بازگرداندن منابع به گره اصلی بعد از رفع خرابی به کار می‌رود. این فرآیندها نقش بسیار مهمی در تضمین دسترسی مداوم به منابع دارند. در این بخش، به تجزیه‌وتحلیل وضعیت منابع در هنگام Failover و Failback پرداخته می‌شود و نحوه مدیریت و پیگیری این فرآیندها با استفاده از ابزارهای مختلف را بررسی خواهیم کرد.

1. مفهوم Failover و Failback

• Failover: زمانی که یک گره یا منبع دچار خرابی می‌شود، منابع به گره دیگر منتقل می‌شوند تا سرویس‌دهی بدون وقفه ادامه یابد. این فرآیند به‌طور خودکار توسط ابزارهای مدیریت کلاستر (مانند Pacemaker) انجام می‌شود.
• Failback: پس از رفع خرابی در گره اصلی، منابع به‌صورت خودکار یا دستی به گره اصلی بازمی‌گردند. این فرآیند به‌طور معمول زمانی انجام می‌شود که گره یا منبع خراب به وضعیت سالم برگشته باشد.

2. تجزیه‌وتحلیل وضعیت منابع در هنگام Failover

در هنگام Failover، زمانی که یک گره یا منبع دچار خرابی می‌شود، سیستم به‌طور خودکار منابع را به گره دیگری که در دسترس است، منتقل می‌کند. این فرآیند ممکن است باعث تغییرات در وضعیت منابع شود که در زیر به بررسی آن می‌پردازیم:

2.1. تغییر وضعیت منابع

• زمانی که Failover رخ می‌دهد، منابعی که قبلاً در گره خراب قرار داشتند به گره سالم منتقل می‌شوند.
• وضعیت منابع در کلاستر تغییر می‌کند و ممکن است منبعی از حالت “Started” به “Stopped” و سپس به گره جدیدی منتقل شود.
• برای پیگیری وضعیت منابع در هنگام Failover، می‌توان از دستورات crm status یا pcs status استفاده کرد.

مثال خروجی دستور crm status در زمان Failover:

Cluster Status:
 Last updated: Fri Mar  9 15:00:00 2025
 Stack: corosync
 Current DC: node-01 (version 1.1.2-1)
 2 nodes and 3 resources configured

 Node node-01: online
 Node node-02: online

 Resource Group: mysql-group
     mysql        (ocf::heartbeat:mysql): Stopped node-01
     mysql-vip    (ocf::heartbeat:IPaddr2): Stopped node-01
     mysql        (ocf::heartbeat:mysql): Started node-02
     mysql-vip    (ocf::heartbeat:IPaddr2): Started node-02

در این مثال:

• منابع mysql و mysql-vip ابتدا در گره node-01 بودند، اما به دلیل خرابی در این گره، منابع به گره node-02 منتقل شدند و وضعیت آن‌ها به “Started” در گره جدید تغییر کرد.

2.2. مدت زمان Failover

یکی از جنبه‌های مهم در Failover مدت زمان لازم برای انتقال منابع از گره خراب به گره سالم است. این مدت زمان ممکن است تحت تأثیر عواملی همچون بار شبکه، تنظیمات کلاستر و وضعیت منابع قرار گیرد.

3. تجزیه‌وتحلیل وضعیت منابع در هنگام Failback

پس از رفع خرابی در گره اصلی، فرآیند Failback آغاز می‌شود و منابع به گره اصلی بازمی‌گردند. وضعیت منابع در این زمان باید دوباره بررسی شود تا مطمئن شویم که منابع به درستی به گره اصلی بازگشته‌اند.

3.1. تغییر وضعیت منابع در Failback

• منابعی که پس از Failover به گره سالم منتقل شده بودند، به گره اصلی بازمی‌گردند.
• وضعیت منابع معمولاً به “Started” در گره اصلی تغییر می‌کند و از گره جدید به “Stopped” تبدیل می‌شود.
• برای مشاهده وضعیت منابع در هنگام Failback، می‌توان از دستورات crm status و pcs status مشابه آنچه در Failover انجام می‌دهیم، استفاده کرد.

مثال خروجی دستور crm status در زمان Failback:

Cluster Status:
 Last updated: Fri Mar  9 15:10:00 2025
 Stack: corosync
 Current DC: node-01 (version 1.1.2-1)
 2 nodes and 3 resources configured

 Node node-01: online
 Node node-02: online

 Resource Group: mysql-group
     mysql        (ocf::heartbeat:mysql): Started node-01
     mysql-vip    (ocf::heartbeat:IPaddr2): Started node-01
     mysql        (ocf::heartbeat:mysql): Stopped node-02
     mysql-vip    (ocf::heartbeat:IPaddr2): Stopped node-02

در این مثال:

• منابع mysql و mysql-vip به گره node-01 بازگشتند و وضعیت آن‌ها به “Started” در گره اصلی تغییر کرد.
• منابع قبلاً در گره node-02 متوقف شدند.

3.2. زمان Failback و اولویت‌بندی

زمان Failback به عواملی همچون وضعیت سیستم، اولویت منابع و سیاست‌های پیکربندی مربوط به Failover و Failback بستگی دارد. در برخی موارد، Failback به‌طور خودکار انجام می‌شود و در برخی موارد نیاز به تنظیمات دستی برای کنترل اولویت‌ها دارد.

4. ابزارهای مفید برای تجزیه‌وتحلیل وضعیت منابع

برای تجزیه‌وتحلیل وضعیت منابع در هنگام Failover و Failback، ابزارهای مختلفی مانند crm status و pcs status در دسترس هستند. علاوه بر این، می‌توان از لاگ‌های Corosync و Pacemaker برای بررسی دقیق‌تر وضعیت گره‌ها و منابع استفاده کرد.

برای مشاهده لاگ‌های Corosync و Pacemaker، از دستورات زیر استفاده کنید:

• مشاهده لاگ‌های Corosync:

  tail -f /var/log/cluster/corosync.log
  

• مشاهده لاگ‌های Pacemaker:

  tail -f /var/log/pacemaker/pacemaker.log
  

این لاگ‌ها اطلاعات دقیقی در مورد خرابی‌ها، Failover و Failback منابع ارائه می‌دهند که می‌توانند به تجزیه‌وتحلیل بیشتر کمک کنند.

جمع بندی

در هنگام Failover و Failback، وضعیت منابع در کلاستر تغییر می‌کند و این تغییرات باید به‌دقت بررسی شوند تا اطمینان حاصل شود که منابع به درستی منتقل شده و به گره‌های سالم بازگشته‌اند. استفاده از دستورات crm status و pcs status به مدیران سیستم کمک می‌کند تا وضعیت کلاستر و منابع را پیگیری کنند. همچنین، بررسی لاگ‌های Corosync و Pacemaker می‌تواند در تجزیه‌وتحلیل دقیق‌تر وضعیت منابع کمک‌کننده باشد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نحوه استفاده از Cluster Log برای ثبت جزئیات خرابی‌ها و انتقال منابع” subtitle=”توضیحات کامل”]برای مدیریت و تجزیه‌وتحلیل خرابی‌ها و فرآیندهای انتقال منابع در کلاسترهای HA (High Availability)، ابزار Cluster Log بسیار مفید است. Cluster Log اطلاعات جزئیاتی درباره وضعیت گره‌ها، منابع، فرآیندهای Failover و Failback، و هر گونه خرابی در کلاستر را ثبت می‌کند. این اطلاعات برای عیب‌یابی و تجزیه‌وتحلیل وضعیت کلاستر در مواقع خرابی و انتقال منابع ضروری است.

در این بخش، به نحوه استفاده از Cluster Log برای ثبت جزئیات خرابی‌ها و فرآیند انتقال منابع می‌پردازیم و همچنین چگونگی دسترسی و تحلیل این لاگ‌ها را توضیح می‌دهیم.

1. مفهوم Cluster Log

Cluster Log مجموعه‌ای از گزارش‌های سیستم است که توسط نرم‌افزارهای کلاستر مانند Pacemaker و Corosync برای ثبت وقایع مهم در فرآیند مدیریت کلاستر ایجاد می‌شود. این لاگ‌ها اطلاعات مربوط به:

• خرابی‌های منابع و گره‌ها
• تغییرات وضعیت منابع در فرآیندهای Failover و Failback
• مشکلات ارتباطی میان گره‌ها
• وضعیت سیستم و خطاهای پیکربندی را ذخیره می‌کنند.

2. تنظیمات Cluster Log

برای فعال‌سازی Cluster Log در کلاسترهای HA، شما باید تنظیمات صحیح را در فایل‌های پیکربندی مربوطه انجام دهید. بسته به ابزار مدیریت کلاستر مورد استفاده، این تنظیمات ممکن است متفاوت باشند. در اینجا، تنظیمات را برای ابزارهای Corosync و Pacemaker شرح می‌دهیم.

2.1. فعال‌سازی Cluster Log در Corosync

برای فعال‌سازی Cluster Log در Corosync، شما باید فایل پیکربندی corosync.conf را ویرایش کرده و بخش مربوط به لاگ‌ها را تنظیم کنید.

1. فایل پیکربندی Corosync را باز کنید:

   sudo nano /etc/corosync/corosync.conf
   

2. بخش لاگ را به شکل زیر تنظیم کنید (در صورتی که این بخش وجود ندارد، آن را اضافه کنید):

   logging {
       fileline    off
       to_syslog   yes
       to_stderr   no
       timestamp   on
       logger {
           # Log to /var/log/cluster/corosync.log
           file /var/log/cluster/corosync.log
           debug   on
       }
   }
   

3. بعد از اعمال تغییرات، فایل را ذخیره کرده و Corosync را مجدداً راه‌اندازی کنید:

   sudo systemctl restart corosync
   

2.2. فعال‌سازی Cluster Log در Pacemaker

در Pacemaker، شما می‌توانید از فایل پیکربندی pacemaker.conf استفاده کنید تا تنظیمات مربوط به لاگ‌برداری را انجام دهید. همچنین، می‌توان برای مشاهده لاگ‌ها از دستور crm استفاده کرد.

1. فایل پیکربندی Pacemaker را باز کنید:

   sudo nano /etc/pacemaker/pacemaker.conf
   

2. مطمئن شوید که بخش‌های زیر برای ذخیره لاگ‌ها به درستی تنظیم شده‌اند:

   logfacility=daemon
   loglevel=debug
   logfile="/var/log/pacemaker/pacemaker.log"
   

3. پس از ویرایش پیکربندی، تغییرات را ذخیره کرده و Pacemaker را مجدداً راه‌اندازی کنید:

   sudo systemctl restart pacemaker
   

3. دسترسی به Cluster Log

پس از تنظیمات صحیح، لاگ‌های مربوط به کلاستر در مسیرهای مشخص‌شده ذخیره خواهند شد. معمولاً مسیرهای زیر برای ذخیره لاگ‌های Corosync و Pacemaker استفاده می‌شوند:

• لاگ Corosync:

  /var/log/cluster/corosync.log
  

• لاگ Pacemaker:

  /var/log/pacemaker/pacemaker.log
  

برای مشاهده لاگ‌ها می‌توانید از دستورات زیر استفاده کنید:

• مشاهده لاگ‌های Corosync:

  sudo tail -f /var/log/cluster/corosync.log
  

• مشاهده لاگ‌های Pacemaker:

  sudo tail -f /var/log/pacemaker/pacemaker.log
  

4. تجزیه‌وتحلیل Cluster Log برای ثبت خرابی‌ها و انتقال منابع

پس از راه‌اندازی Cluster Log، شما می‌توانید با استفاده از این لاگ‌ها اطلاعات ارزشمندی را درباره خرابی‌ها و انتقال منابع در کلاستر بدست آورید. در اینجا، چند نکته کلیدی در تجزیه‌وتحلیل Cluster Log آورده شده است:

4.1. ثبت خرابی‌ها

در صورت خرابی یک گره یا منبع، اطلاعات مربوط به خطاها و خرابی‌ها در لاگ‌ها ثبت می‌شود. در لاگ‌ها، معمولاً می‌توانید پیام‌هایی با عناوین زیر پیدا کنید:

• “Node failure detected”
• “Resource failed”
• “Resource moved to another node”

مثال:

Mar  9 15:00:00 node-01 corosync[1234]: [TOTEM] A node failure has been detected for node node-01
Mar  9 15:00:05 node-01 pacemaker[1235]: [pcmk] Node node-01 failed, moving resource to node-02

در این مثال، خرابی گره node-01 شناسایی شده و منابع به گره node-02 منتقل شده‌اند.

4.2. ثبت فرآیند انتقال منابع (Failover)

هنگامی که منابع از یک گره به گره دیگر منتقل می‌شوند، جزئیات مربوط به این تغییرات نیز در Cluster Log ثبت می‌شود. این اطلاعات معمولاً شامل نام منابع و گره‌های مبدا و مقصد می‌باشد.

مثال:

Mar  9 15:05:00 node-02 pacemaker[1235]: [pcmk] Resource mysql moved from node-01 to node-02 due to node failure

4.3. ثبت فرآیند Failback

زمانی که خرابی در گره اصلی رفع می‌شود و منابع به آن بازمی‌گردند، این عمل نیز در Cluster Log ثبت می‌شود.

مثال:

Mar  9 15:20:00 node-01 pacemaker[1235]: [pcmk] Resource mysql moved back to node-01 after recovery

5. استفاده از ابزارهای مانیتورینگ برای تجزیه‌وتحلیل بهتر

برای تجزیه‌وتحلیل و مشاهده دقیق‌تر وضعیت کلاستر، می‌توانید از ابزارهای مانیتورینگ مانند Grafana و Prometheus که به کلاستر HA متصل می‌شوند، استفاده کنید. این ابزارها می‌توانند داده‌های موجود در Cluster Log را به‌صورت گرافیکی نمایش دهند و تجزیه‌وتحلیل بهتری را فراهم کنند.

جمع بندی

استفاده از Cluster Log در کلاسترهای HA، ابزاری بسیار مفید برای ثبت جزئیات خرابی‌ها و فرآیندهای انتقال منابع است. با تنظیم صحیح Cluster Log در ابزارهای Corosync و Pacemaker، شما می‌توانید به‌راحتی اطلاعات دقیق و جزئی درباره خرابی‌ها، Failover و Failback‌ها بدست آورید. این اطلاعات به شما کمک می‌کند تا مشکلات سیستم را شناسایی کرده و راه‌حل‌های بهینه‌ای برای رفع آن‌ها پیدا کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 7. آزمایش و بهینه‌سازی انتقال منابع”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”آزمایش Failover و Failback در شرایط مختلف” subtitle=”توضیحات کامل”]آزمایش فرآیندهای Failover و Failback در کلاسترهای HA (High Availability) یک مرحله حیاتی است تا اطمینان حاصل شود که منابع به‌درستی در هنگام خرابی‌ها جابجا می‌شوند و پس از رفع خرابی به گره‌های اصلی بازمی‌گردند. این آزمایش‌ها می‌توانند در شرایط مختلف از جمله خرابی‌های گره‌ها، خرابی‌های شبکه، یا خرابی منابع انجام شوند تا اطمینان حاصل شود که کلاستر قادر به بازیابی و بازگشت به وضعیت نرمال است.

در این بخش، مراحل آزمایش Failover و Failback را در شرایط مختلف شرح خواهیم داد و نحوه انجام این آزمایش‌ها را با استفاده از دستورات و ابزارهای مختلف بررسی خواهیم کرد.

1. مفهوم Failover و Failback

قبل از انجام آزمایش‌ها، لازم است که مفهوم Failover و Failback را به‌طور خلاصه توضیح دهیم:

• Failover: فرآیند انتقال منابع از یک گره خراب به گره سالم به‌منظور حفظ دسترسی به منابع در کلاستر.
• Failback: فرآیند بازگشت منابع به گره اولیه پس از رفع خرابی یا مشکل در گره مقصد.

2. شرایط مختلف برای آزمایش Failover و Failback

برای آزمایش صحیح Failover و Failback، باید شرایط مختلفی را شبیه‌سازی کنیم که می‌تواند بر روی منابع و گره‌ها تأثیر بگذارد. در اینجا چندین سناریو برای آزمایش این فرآیندها آورده شده است:

2.1. خرابی گره

یکی از شایع‌ترین سناریوها برای آزمایش Failover، شبیه‌سازی خرابی یک گره است. در این سناریو، ما می‌خواهیم ببینیم که منابع چگونه از گره خراب به گره سالم منتقل می‌شوند.

2.2. خرابی منابع

در این سناریو، ما به طور عمدی یکی از منابع کلاستر (مثلاً یک دیتابیس یا سرویس وب) را متوقف می‌کنیم تا ببینیم که Failover چگونه انجام می‌شود و آیا منابع به‌درستی به گره دیگر منتقل می‌شوند.

2.3. قطع ارتباط شبکه

قطع ارتباط شبکه بین گره‌ها می‌تواند باعث ایجاد مشکل در ارتباط میان گره‌ها شود. آزمایش Failover در چنین شرایطی مهم است تا ببینیم که کلاستر چگونه به این شرایط واکنش نشان می‌دهد.

2.4. رفع خرابی و Failback

پس از شبیه‌سازی خرابی‌ها، مهم است که فرآیند Failback را نیز آزمایش کنیم تا مطمئن شویم منابع پس از رفع خرابی به گره اولیه باز می‌گردند.

3. نحوه انجام آزمایش Failover

برای انجام آزمایش Failover، ابتدا باید اطمینان حاصل کنید که Pacemaker و Corosync به درستی پیکربندی شده‌اند و در حالت فعال هستند.

3.1. شبیه‌سازی خرابی گره

1. ابتدا وضعیت کلاستر را بررسی کنید:

   crm status
   

2. سپس یک گره را غیرفعال کنید تا فرآیند Failover فعال شود. برای این منظور از دستور زیر استفاده کنید:

   sudo crm node standby <node-name>
   

   به عنوان مثال، اگر گره‌ای به نام node-01 دارید، می‌توانید آن را به حالت استندبای ببرید:

   sudo crm node standby node-01
   

   این عمل باعث می‌شود که منابع از گره node-01 به گره‌های سالم دیگر منتقل شوند.

3. پس از انجام این عمل، وضعیت کلاستر را دوباره بررسی کنید تا مطمئن شوید منابع به گره سالم منتقل شده‌اند:

   crm status
   

4. حالا، باید اطمینان حاصل کنید که منابع به درستی از گره خراب به گره سالم منتقل شده‌اند. در صورتی که همه چیز به درستی منتقل شده باشد، باید پیامی مشابه زیر را مشاهده کنید:

   Resource mysql migrated to node-02
   

4. نحوه انجام آزمایش Failback

برای آزمایش Failback، شما باید شرایطی را فراهم کنید که خرابی از گره‌ای که منابع به آن منتقل شده‌اند، رفع شود و منابع به گره اولیه بازگردند.

4.1. رفع خرابی و بازگرداندن منابع

1. ابتدا گره‌ای که غیرفعال کرده‌اید را دوباره فعال کنید:

   sudo crm node online <node-name>
   

   به عنوان مثال، برای فعال کردن node-01 از دستور زیر استفاده کنید:

   sudo crm node online node-01
   

2. سپس از دستور زیر برای بازگشت منابع به گره اولیه استفاده کنید:

   crm resource move <resource-name> <node-name>
   

   به عنوان مثال، برای انتقال دوباره منابع به گره node-01 از دستور زیر استفاده کنید:

   crm resource move mysql node-01
   

3. حالا وضعیت کلاستر را بررسی کنید تا مطمئن شوید که منابع به گره اولیه بازگشته‌اند:

   crm status
   

   در صورتی که منابع به درستی به گره اولیه بازگشته باشند، پیامی مشابه زیر را مشاهده خواهید کرد:

   Resource mysql moved back to node-01
   

5. شبیه‌سازی خرابی منابع و آزمایش Failover

اگر قصد دارید فرآیند Failover را در سطح منابع (به‌جای گره‌ها) آزمایش کنید، می‌توانید یکی از منابع کلاستر را به‌طور عمدی متوقف کنید.

1. ابتدا وضعیت منابع را بررسی کنید:

   crm status
   

2. سپس یک منبع را به‌طور عمدی متوقف کنید:

   crm resource stop <resource-name>
   

   به عنوان مثال، اگر منبع mysql را می‌خواهید متوقف کنید:

   crm resource stop mysql
   

3. پس از متوقف کردن منبع، مطمئن شوید که منابع به گره سالم منتقل شده‌اند. وضعیت کلاستر را دوباره بررسی کنید:

   crm status
   

4. بعد از اتمام آزمایش، منبع را دوباره فعال کنید:

   crm resource start <resource-name>
   

   به عنوان مثال:

   crm resource start mysql
   

6. قطع ارتباط شبکه و آزمایش Failover

برای آزمایش Failover در شرایط قطع ارتباط شبکه بین گره‌ها، مراحل زیر را دنبال کنید:

1. ابتدا وضعیت کلاستر را بررسی کنید:

   crm status
   

2. سپس یکی از گره‌ها را از شبکه جدا کنید تا ارتباط بین گره‌ها قطع شود. می‌توانید از دستور ifdown برای غیرفعال کردن شبکه استفاده کنید:

   sudo ifdown eth0
   

   این کار باعث قطع ارتباط گره از شبکه خواهد شد.

3. وضعیت کلاستر را دوباره بررسی کنید تا ببینید که آیا فرآیند Failover به درستی انجام شده است یا خیر.
4. پس از آزمایش، ارتباط شبکه را دوباره برقرار کنید:

   sudo ifup eth0
   

جمع بندی

آزمایش Failover و Failback در شرایط مختلف از اهمیت ویژه‌ای برخوردار است تا اطمینان حاصل شود که منابع کلاستر به درستی مدیریت می‌شوند و سیستم قادر به بازیابی از خرابی‌ها است. در این بخش، مراحل آزمایش Failover و Failback در شرایط مختلف از جمله خرابی گره، خرابی منابع، قطع ارتباط شبکه، و رفع خرابی شرح داده شد. این آزمایش‌ها به شما کمک می‌کنند تا عملکرد کلاستر را در مواقع بحرانی ارزیابی کنید و از قابلیت‌های بالای کلاسترهای HA بهره‌برداری نمایید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”بهینه‌سازی زمان انتقال منابع و کاهش تأخیر در کلاستر” subtitle=”توضیحات کامل”]زمان انتقال منابع و تأخیر در کلاسترهای HA (High Availability) می‌تواند بر عملکرد سیستم و تجربه کاربری تأثیر بگذارد. به همین دلیل، بهینه‌سازی این فرآیندها برای حفظ در دسترس بودن و کارایی سیستم از اهمیت زیادی برخوردار است. در این بخش، به بررسی روش‌های مختلف برای کاهش تأخیر در انتقال منابع بین گره‌ها و بهینه‌سازی زمان انتقال منابع می‌پردازیم.

1. مفهوم زمان انتقال منابع و تأخیر

قبل از بررسی روش‌های بهینه‌سازی، لازم است که مفهوم “زمان انتقال منابع” و “تأخیر” را به‌طور دقیق بیان کنیم:

• زمان انتقال منابع: مدت زمانی که طول می‌کشد تا منابع از یک گره به گره دیگر در کلاستر منتقل شوند.
• تأخیر: زمان تأخیر در انتقال منابع، که می‌تواند ناشی از مشکلات شبکه، تأخیر در پردازش منابع، یا پیکربندی‌های اشتباه باشد.

2. عوامل تأثیرگذار بر زمان انتقال منابع

چندین عامل می‌توانند بر زمان انتقال منابع و تأخیر تأثیر بگذارند. این عوامل شامل:

• پیکربندی شبکه: شبکه‌های کند یا پرخطا می‌توانند باعث افزایش تأخیر در انتقال منابع شوند.
• سرعت ذخیره‌سازی: عملکرد ذخیره‌سازی (مثل iSCSI، NFS، یا SAN) بر سرعت انتقال داده‌ها تأثیر می‌گذارد.
• پیکربندی اشتباه کلاستر: تنظیمات نادرست در تنظیمات Pacemaker یا Corosync می‌تواند زمان انتقال منابع را افزایش دهد.
• بار اضافی گره‌ها: گره‌هایی که بار زیادی دارند ممکن است زمان بیشتری برای انتقال منابع نیاز داشته باشند.

3. بهینه‌سازی زمان انتقال منابع

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

3.1. استفاده از انتقال منابع سریع‌تر (Resource Migration)

استفاده از قابلیت‌های Migration در کلاستر می‌تواند زمان انتقال منابع را کاهش دهد. به‌ویژه، استفاده از Resource Constraints و Location Constraints برای تعیین گره‌های مقصد می‌تواند تأثیر زیادی در کاهش زمان انتقال داشته باشد.

برای مثال، اگر می‌خواهید منابع را سریع‌تر به گره مقصد منتقل کنید، می‌توانید از دستور زیر برای انتقال سریع منابع استفاده کنید:

crm resource migrate <resource-name> <destination-node>

این دستور باعث می‌شود که منابع از گره فعلی به گره مقصد سریعاً منتقل شوند. همچنین، برای کاهش زمان انتقال، می‌توان از ویژگی‌های Resource Stickiness و Failback برای کاهش جابجایی‌های غیرضروری منابع استفاده کرد.

3.2. بهینه‌سازی شبکه

شبکه یکی از مهم‌ترین عواملی است که تأثیر زیادی بر زمان انتقال منابع دارد. برای بهینه‌سازی شبکه و کاهش تأخیر، می‌توانید اقدامات زیر را انجام دهید:

• استفاده از شبکه‌های سریع‌تر با پهنای باند بالا و تأخیر پایین.
• تنظیم QoS (Quality of Service) برای اولویت‌بندی ترافیک کلاستر و منابع.
• استفاده از شبکه‌های اختصاصی برای ارتباط گره‌های کلاستر به منظور کاهش تأخیر ناشی از شبکه‌های عمومی.

در صورتی که گره‌ها در یک شبکه محلی (LAN) قرار دارند، این اقدامات می‌توانند تأثیر زیادی در کاهش تأخیر انتقال منابع داشته باشند.

3.3. تنظیمات Pacemaker و Corosync

پیکربندی صحیح Pacemaker و Corosync می‌تواند بر سرعت و کارایی انتقال منابع تأثیر بگذارد. برخی از تنظیماتی که می‌توانند به کاهش تأخیر کمک کنند عبارتند از:

• استفاده از اشکال‌های اولویت‌دار برای منابع: تعیین اولویت‌های منابع به‌طوری‌که منابع با اولویت بالا سریع‌تر از منابع با اولویت پایین‌تر جابجا شوند.
• تنظیم رقابت کمتر برای منابع: به‌جای اینکه منابع در گره‌های مختلف رقابت کنند، می‌توانید به آن‌ها اولویت‌های خاصی بدهید.
• کاهش زمان تأخیر برای اتصال‌های شبکه: تنظیمات مربوط به زمان تأخیر و زمان انتظار (Timeout) برای Pacemaker و Corosync می‌توانند بر سرعت واکنش کلاستر تأثیر بگذارند.

مثال تنظیمات Pacemaker برای بهینه‌سازی زمان انتقال منابع:

sudo crm configure property stonith-enabled=false
sudo crm configure property no-quorum-policy=ignore

این تنظیمات برای کاهش تأخیر و سرعت بالاتر در هنگام انتقال منابع در کلاستر مفید هستند.

3.4. بهینه‌سازی منابع ذخیره‌سازی

عملکرد منابع ذخیره‌سازی نیز می‌تواند تأثیر زیادی بر زمان انتقال منابع داشته باشد. برای بهینه‌سازی ذخیره‌سازی و کاهش زمان انتقال، موارد زیر را در نظر بگیرید:

• استفاده از ذخیره‌سازی با سرعت بالا مانند SSD به جای هارد دیسک‌های سنتی.
• پیکربندی RAID برای افزایش سرعت دسترسی به داده‌ها.
• استفاده از Fencing برای جلوگیری از دسترسی همزمان به منابع و کاهش مشکلات مربوط به همزمانی.

برای پیکربندی منابع ذخیره‌سازی، می‌توانید از تنظیمات زیر استفاده کنید:

sudo crm configure primitive iSCSI-Resource ocf:heartbeat:iSCSI \
  op monitor interval="30s" timeout="20s" \
  op start interval="0" timeout="60s" \
  op stop interval="0" timeout="60s"

این دستور برای تنظیم منابع ذخیره‌سازی iSCSI استفاده می‌شود و زمان انتقال داده‌ها را کاهش می‌دهد.

3.5. استفاده از ویژگی‌های Advanced Resource Management

Advanced Resource Management در کلاسترهای HA می‌تواند به کاهش تأخیر در انتقال منابع کمک کند. ویژگی‌هایی مانند Resource Stickiness، Location Constraints، و Order Constraints به شما این امکان را می‌دهند که نحوه جابجایی منابع را دقیق‌تر کنترل کنید.

به عنوان مثال، برای تنظیم Resource Stickiness به‌منظور جلوگیری از جابجایی‌های غیرضروری منابع، می‌توانید از دستور زیر استفاده کنید:

sudo crm resource constraint resource-stickiness <resource-name> <value>

این دستور باعث می‌شود که منابع به مدت طولانی‌تر در گره خود باقی بمانند و تنها در صورت نیاز به انتقال جابجا شوند.

4. تست و ارزیابی

برای ارزیابی بهینه‌سازی‌ها و کاهش زمان انتقال منابع، می‌توانید از ابزارهای مانیتورینگ و ارزیابی زمان انتقال استفاده کنید. ابزارهایی مانند Cluster Log و crm status می‌توانند به شما کمک کنند تا تأخیرهای ناشی از انتقال منابع را شبیه‌سازی و تحلیل کنید.

جمع بندی

بهینه‌سازی زمان انتقال منابع و کاهش تأخیر در کلاستر از جمله اقدامات حیاتی برای حفظ عملکرد سیستم است. با استفاده از روش‌هایی مانند بهینه‌سازی شبکه، پیکربندی مناسب Pacemaker و Corosync، استفاده از منابع ذخیره‌سازی سریع، و مدیریت منابع به‌طور پیشرفته، می‌توان زمان انتقال منابع را کاهش داده و تأخیرها را به حداقل رساند. این بهینه‌سازی‌ها نه تنها کارایی کلاستر را بهبود می‌بخشند، بلکه به حفظ در دسترس بودن منابع و بهبود تجربه کاربری کمک می‌کنند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”شبیه‌سازی شرایط بحرانی و ارزیابی عملکرد سیستم در شرایط خرابی” subtitle=”توضیحات کامل”]شبیه‌سازی شرایط بحرانی و ارزیابی عملکرد سیستم در هنگام خرابی، از جمله فرآیندهای حیاتی در طراحی و نگهداری سیستم‌های High Availability (HA) است. این فرآیندها به شما کمک می‌کنند تا عملکرد سیستم را در مواقع بحرانی مورد ارزیابی قرار دهید و از عملکرد درست سیستم در شرایط مختلف خرابی اطمینان حاصل کنید. در این بخش، به بررسی نحوه شبیه‌سازی شرایط بحرانی، ابزارها و تکنیک‌های مورد استفاده، و ارزیابی عملکرد سیستم در این شرایط خواهیم پرداخت.

1. شبیه‌سازی شرایط بحرانی در کلاستر

شبیه‌سازی شرایط بحرانی، به معنای ایجاد سناریوهایی است که به‌طور مصنوعی باعث خرابی منابع یا گره‌های سیستم می‌شود. این شبیه‌سازی‌ها به شما این امکان را می‌دهند که از عملکرد کلاستر و پاسخ‌گویی آن در برابر خرابی‌ها مطمئن شوید. چندین روش برای شبیه‌سازی شرایط بحرانی وجود دارد که در اینجا به برخی از آن‌ها اشاره می‌کنیم:

1.1. شبیه‌سازی خرابی گره‌ها

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

برای شبیه‌سازی خرابی گره، از دستور زیر استفاده می‌کنیم:

sudo pcs cluster stop <node-name>

این دستور باعث می‌شود گره انتخاب‌شده به‌طور موقت از کلاستر خارج شود و منابع موجود در آن به گره‌های دیگر منتقل شوند. پس از آن می‌توانیم عملکرد سیستم را از نظر سرعت انتقال منابع، زمان Failover، و واکنش به خرابی بررسی کنیم.

برای بازگرداندن گره، از دستور زیر استفاده می‌کنیم:

sudo pcs cluster start <node-name>

1.2. شبیه‌سازی خرابی منابع

شبیه‌سازی خرابی منابع به این معناست که یک یا چند منبع (مثل سرویس‌ها یا دیتابیس‌ها) از دسترس خارج شوند تا ارزیابی کنیم که کلاستر چگونه از این خرابی‌ها واکنش نشان می‌دهد و منابع را بین گره‌ها توزیع می‌کند.

برای شبیه‌سازی خرابی یک منبع، از دستور زیر استفاده می‌کنیم:

sudo crm resource stop <resource-name>

این دستور باعث می‌شود که منبع موردنظر به‌طور موقت متوقف شود و Failover به گره دیگر صورت گیرد. پس از انجام این عملیات، می‌توانیم زمان واکنش و عملیات Failover را اندازه‌گیری کنیم.

1.3. شبیه‌سازی مشکلات شبکه

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

برای شبیه‌سازی قطع شبکه، می‌توانید از دستور زیر در لینوکس استفاده کنید:

sudo ifconfig eth0 down

این دستور باعث می‌شود که شبکه قطع شود و کلاستر مجبور به جابجایی منابع شود. پس از بررسی نتیجه، می‌توان زمان واکنش Failover و میزان تأثیرگذاری بر عملکرد سیستم را ارزیابی کرد.

برای بازگرداندن اتصال شبکه، از دستور زیر استفاده کنید:

sudo ifconfig eth0 up

2. ارزیابی عملکرد سیستم در شرایط خرابی

پس از شبیه‌سازی خرابی‌ها، باید عملکرد سیستم را ارزیابی کنید. این ارزیابی به شما کمک می‌کند تا ببینید آیا سیستم به درستی منابع را بین گره‌ها منتقل می‌کند، زمان Failover چقدر است، و آیا کلاستر توانایی بازیابی سریع از خرابی‌ها را دارد یا خیر.

2.1. بررسی زمان Failover و Failback

برای ارزیابی زمان Failover و Failback، می‌توان از دستورات زیر برای مانیتورینگ وضعیت منابع استفاده کرد:

sudo crm status

این دستور اطلاعات کاملی درباره وضعیت منابع و وضعیت گره‌ها ارائه می‌دهد. با بررسی این اطلاعات می‌توان زمان دقیق جابجایی منابع و بازیابی را اندازه‌گیری کرد.

برای بررسی وضعیت Failback، می‌توانید از دستور زیر استفاده کنید:

sudo pcs resource status

این دستور وضعیت منابع را پس از بازگشت به گره اصلی بررسی می‌کند و به شما زمان و صحت انجام عملیات Failback را نشان می‌دهد.

2.2. بررسی ترافیک و تأخیر شبکه

برای ارزیابی تأثیر خرابی‌ها بر عملکرد شبکه، می‌توانید از ابزارهایی مانند ping یا iperf برای بررسی تأخیر شبکه استفاده کنید.

برای بررسی تأخیر شبکه، می‌توانید از دستور زیر استفاده کنید:

ping <node-ip>

این دستور زمان پاسخ‌دهی به گره‌های مختلف را نشان می‌دهد. همچنین، با استفاده از iperf می‌توانید سرعت انتقال داده‌ها را قبل و بعد از خرابی ارزیابی کنید.

2.3. بررسی صحت عملکرد منابع

برای بررسی صحت عملکرد منابع پس از Failover و Failback، از دستور زیر برای بررسی وضعیت منابع استفاده کنید:

sudo crm resource show <resource-name>

این دستور به شما نشان می‌دهد که آیا منابع به درستی به گره جدید منتقل شده‌اند و در صورت انجام Failback، آیا به گره اولیه برگشته‌اند یا خیر.

3. تجزیه و تحلیل گزارش‌های کلاستر

گزارش‌های کلاستر (Cluster Logs) یکی از منابع مهم برای بررسی دقیق خرابی‌ها و ارزیابی عملکرد در شرایط بحرانی هستند. این گزارش‌ها می‌توانند اطلاعات ارزشمندی درباره زمان دقیق خرابی‌ها، میزان تأثیرگذاری، و زمان بازیابی ارائه دهند.

برای مشاهده گزارش‌های کلاستر، می‌توانید از دستور زیر استفاده کنید:

sudo journalctl -u pacemaker

این دستور گزارش‌هایی مربوط به Pacemaker را نمایش می‌دهد که شامل جزئیات مربوط به خرابی‌ها، Failover، و Failback است.

همچنین، برای مشاهده گزارش‌های مربوط به Corosync، از دستور زیر استفاده کنید:

sudo journalctl -u corosync

این دستور جزئیات دقیق‌تری از وضعیت ارتباطات و هماهنگی بین گره‌های کلاستر در اختیار شما قرار می‌دهد.

جمع بندی

شبیه‌سازی شرایط بحرانی و ارزیابی عملکرد سیستم در شرایط خرابی یک گام اساسی در تضمین عملکرد بهینه سیستم‌های HA است. با شبیه‌سازی سناریوهای مختلف خرابی، ارزیابی زمان Failover و Failback، و تحلیل تأثیر خرابی‌ها بر عملکرد منابع و شبکه، می‌توان بهبودهای لازم را در پیکربندی‌ها اعمال کرد و از کارایی بالای سیستم در شرایط بحرانی اطمینان حاصل نمود. همچنین، گزارش‌های کلاستر و ابزارهای مانیتورینگ می‌توانند به شما کمک کنند تا دقیقاً بفهمید کجا مشکلات وجود دارند و چگونه می‌توان آن‌ها را برطرف کرد.[/cdb_course_lesson][/cdb_course_lessons]

[cdb_course_lessons title=”پاسخ به سوالات فنی کاربران”][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”free” title=”پشتیبانی دائمی و در لحظه” subtitle=”توضیحات کامل”]ما در این دوره تمام تلاش خود را کرده‌ایم تا محتوایی جامع و کاربردی ارائه دهیم که شما را برای ورود به دنیای حرفه‌ای آماده کند. اما اگر در طول دوره یا پس از آن با سوالات فنی، چالش‌ها یا حتی مشکلاتی در اجرای مطالب آموزشی مواجه شدید، نگران نباشید!

1. پرسش‌های شما، بخش مهمی از دوره است:
   هر سوال یا مشکلی که مطرح کنید، با دقت بررسی شده و پاسخ کامل و کاربردی برای آن ارائه می‌شود. علاوه بر این، سوالات و پاسخ‌های شما به دوره اضافه خواهند شد تا برای سایر کاربران نیز مفید باشد.
2. پشتیبانی دائمی و در لحظه:
   تیم ما همواره آماده پاسخگویی به سوالات شماست. هدف ما این است که شما با خیالی آسوده بتوانید مهارت‌های خود را به کار بگیرید و پروژه‌های واقعی را با اعتماد به نفس کامل انجام دهید.
3. آپدیت دائمی دوره:
   این دوره به طور مداوم به‌روزرسانی می‌شود تا همگام با نیازهای جدید و سوالات کاربران تکمیل‌تر و بهتر گردد. هر نکته جدید یا مشکل رایج، در نسخه‌های بعدی دوره قرار خواهد گرفت.

حرف آخر

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

📩 اگر سوالی دارید یا به مشکلی برخوردید، همین حالا مطرح کنید!
ما در کوتاه‌ترین زمان ممکن پاسخ شما را ارائه خواهیم داد. 🙌[/cdb_course_lesson][/cdb_course_lessons]