مدیریت سرویس‌های PVM

۱. مرور کلی

معماری مدیریت سرویس‌های PVM طراحی شده تا یک Node هایپروایزور را از حالت راه‌اندازی اولیه سیستم‌عامل به وضعیت عملیاتی کامل برساند؛ وضعیتی که در آن سرویس‌های Cluster، فضای ذخیره‌سازی اشتراکی و زیرساخت PVM آماده استفاده هستند.

این سیستم بر پایه دو فاز مجزا طراحی شده است:

فاز اول — راه‌اندازی زیرساخت

تنظیم پیکربندی شبکه Node
برقراری عضویت در Cluster و رسیدن به Quorum
راه‌اندازی Distributed Lock Manager یا DLM
Mount کردن فایل‌سیستم اشتراکی GFS

فاز دوم — راه‌اندازی سرویس‌های PVM

راه‌اندازی سرویس‌هایی که زیرساخت اصلی PVM را فراهم می‌کنند
راه‌اندازی مدیر Hypervisor و سرویس‌های پشتیبان
ارائه یک نقطه مدیریت واحد از طریق Meta-Service به نام pvm

وابستگی‌های تعریف‌شده در systemd میان این سرویس‌ها کاملاً هدفمند هستند. سرویس‌ها صرفاً به ترتیب دلخواه اجرا نمی‌شوند؛ هر سرویس مهم تا زمانی که زیرساخت موردنیازش به وضعیت لازم نرسیده باشد، اجازه شروع ندارد.

زنجیره وابستگی به شکل زیر است:

                     فاز زیرساخت
                     =============

                          +---------+
                          |  sbone  |
                          | Network |
                          +----+----+
                               |
                               v
                        +-------------+
                        |  corosync   |
                        |   Cluster   |
                        |   /Quorum   |
                        +------+------+
                               |
                               v
                     +------------------+
                     | pvm-wait-for-    |
                     |     quorum       |
                     +--------+---------+
                              |
                              v
                        +-----------+
                        |    dlm    |
                        | Lock Mgmt |
                        +-----+-----+
                              |
                              v
                     +------------------+
                     | pvm-gfs-manager  |
                     |  Mount GFS       |
                     +--------+---------+
                              |
                              |
                 زیرساخت آماده است
                              |
                              v
                     ====================
                       فاز سرویس‌های PVM
                     ====================
                              |
                              v
                        +-----------+
                        |    pvm    |
                        | Meta Unit |
                        +-----+-----+
                              |
          +-------------------+-------------------+
          |                   |                   |
          v                   v                   v
      +--------+         +---------+        +----------+
      | sballd |         | plogger |        |pvm-engine|
      +----+---+         +---------+        +----------+
           |
           v
       +--------+
       | sabad  |
       | API GW |
       +--------+

به خاطر داشته باشید

سرویس‌های دیگر PVM نیز ممکن است توسط pvm مدیریت شوند

۲. مدل راه‌اندازی دو فازی

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

Node ابتدا باید یک محیط Cluster و فضای ذخیره‌سازی معتبر ایجاد کند.

فاز ۱ — زیرساخت

فاز اول موارد زیر را برقرار می‌کند:

پیکربندی شبکه
ارتباطات Cluster
Quorum کلاستر
قفل توزیع‌شده (Distributed Locking)
دسترسی به فایل‌سیستم اشتراکی

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

فاز ۲ — سرویس‌های PVM

پس از آماده شدن زیرساخت، Meta-Service به نام pvm می‌تواند راه‌اندازی شود. این سرویس مسئول بالا آوردن سرویس‌های PVM است که به زیرساخت پایه وابسته‌اند.

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

۳. سرویس‌های زیرساختی

۳.۱ سرویس `sbone`

sbone مسئول برقراری پیکربندی پایه Cluster در Node است. یکی از مهم‌ترین وظایف آن در زمان بوت، تنظیم پیکربندی شبکه است.

سیستم‌های PVM برای تنظیم آدرس‌های شبکه Node به NetworkManager متکی نیستند. در عوض، sbone پیکربندی شبکه موردنیاز، از جمله اختصاص IP، را خود انجام می‌دهد.

بنابراین sbone یک پیش‌نیاز مهم برای Cluster Stack است.

sbone
  |
  +-- پیکربندی Cluster
  +-- پیکربندی شبکه
           |
           v
       corosync

۴. سرویس `corosync` — عضویت در Cluster و Quorum

پس از برقراری پیکربندی پایه Node، corosync لایه ارتباطی و عضویت Cluster را فراهم می‌کند. Corosync به Cluster اجازه می‌دهد تعیین کند کدام Nodeها در حال حاضر در Cluster شرکت دارند و آیا Cluster به Quorum رسیده است یا خیر.

Quorum برای جلوگیری از Split-Brain حیاتی است.

وضعیت Split-Brain زمانی رخ می‌دهد که بخش‌های مختلف یک Cluster به‌طور مستقل باور کنند که اقتدار لازم را دارند. برای یک Cluster با فضای ذخیره‌سازی اشتراکی، این وضعیت می‌تواند بسیار خطرناک باشد، زیرا چندین Node ممکن است بدون دیدگاه یکسانی از عضویت Cluster، بخواهند به منابع اشتراکی دسترسی داشته باشند یا آن‌ها را تغییر دهند.

sbone
  |
  v
corosync
  |
  v
cluster به quorum می‌رسد

رسیدن Corosync به وضعیت Active، تضمین نمی‌کند که Cluster به Quorum رسیده باشد. این تمایز دلیل وجود سرویس بعدی است.

۵. سرویس `pvm-wait-for-quorum`

۵.۱ هدف

pvm-wait-for-quorum برای پر کردن شکاف بین دو حالت زیر وجود دارد:

راه‌اندازی سرویس Cluster
آماده بودن واقعی Cluster برای استفاده ایمن

فعال بودن corosync.service به‌تنهایی کافی نیست تا تضمین کند که Cluster به Quorum رسیده است. این موضوع به‌ویژه برای DLM اهمیت دارد.

۵.۲ چرا DLM نمی‌تواند پیش از Quorum راه‌اندازی شود

DLM قفل توزیع‌شده‌ای را فراهم می‌کند که فایل‌سیستم Cluster به آن نیاز دارد. GFS به DLM متکی است تا دسترسی به فایل‌سیستم اشتراکی را بین Nodeهای Cluster هماهنگ کند.

Cluster / Quorum
       |
       v
      DLM
       |
       v
      GFS
       |
       v
 Shared Storage

راه‌اندازی DLM پیش از رسیدن Cluster به Quorum خطرناک است. اگر DLM در حالی راه‌اندازی شود که Cluster هنوز به Quorum نرسیده، Node ممکن است Fence شود.

این رفتار از دیدگاه Cluster عمدی است: Fencing یک مکانیزم ایمنی طراحی شده برای جلوگیری از عملکرد ناایمن Cluster است. اما در طول بوت عادی، اجازه دادن به DLM برای راه‌اندازی زودهنگام می‌تواند یک Fencing غیرضروری ایجاد کند.

۵.۳ دروازه Quorum

pvm-wait-for-quorum تا زمانی که Cluster واقعاً به Quorum برسد، صبر می‌کند. DLM با استفاده از رابطه After= در systemd، پس از این سرویس اجرا می‌شود.

corosync راه‌اندازی می‌شود
      |
      v
عضویت در Cluster برقرار می‌شود
      |
      v
pvm-wait-for-quorum
      |
      | منتظر می‌ماند
      v
cluster به quorum می‌رسد
      |
      v
pvm-wait-for-quorum فعال می‌شود
      |
      v
DLM می‌تواند راه‌اندازی شود

هدف واقعی این است:

DLM را تا زمانی که Cluster به Quorum نرسیده، راه‌اندازی نکن.

pvm-wait-for-quorum این نیاز را به‌صراحت بیان می‌کند.

۶. سرویس `dlm` — Distributed Lock Manager

پس از برقراری Quorum، DLM می‌تواند به‌صورت ایمن راه‌اندازی شود. DLM قابلیت قفل توزیع‌شده‌ای را فراهم می‌کند که فایل‌سیستم Cluster به آن نیاز دارد. بنابراین DLM یک وابستگی زیرساختی است، نه یک سرویس کاربردی PVM.

corosync
    |
    v
quorum
    |
    v
pvm-wait-for-quorum
    |
    v
dlm
    |
    v
GFS

تمایز مهم:

DLM قفل توزیع‌شده فراهم می‌کند.
GFS فایل‌سیستم Cluster را فراهم می‌کند.
pvm-gfs-manager Mount واقعی GFS را مدیریت می‌کند.

۷. سرویس `pvm-gfs-manager` — مدیریت GFS

هدف pvm-gfs-manager کاملاً مشخص است:

پس از راه‌اندازی DLM، فضای ذخیره‌سازی اشتراکی GFS را به‌صورت خودکار Mount کن.

به‌جای اینکه مدیر سیستم مجبور باشد DLM را تأیید کرده و سپس فایل‌سیستم را به‌صورت دستی Mount کند، GFS Manager فرایند Mount را بخشی از زنجیره وابستگی‌های systemd می‌کند.

Quorum
   |
   v
pvm-wait-for-quorum
   |
   v
DLM
   |
   v
pvm-gfs-manager
   |
   v
GFS mounted

۸. زنجیره کامل زیرساخت

زنجیره وابستگی کامل فاز اول به شکل زیر است:

                    +---------+
                    |  sbone  |
                    | Network |
                    +----+----+
                         |
                         v
                   +-----------+
                   | corosync  |
                   +-----+-----+
                         |
                         v
                +------------------+
                |  Cluster Quorum  |
                |    Required      |
                +--------+---------+
                         |
                         v
             +-----------------------+
             | pvm-wait-for-quorum   |
             +-----------+-----------+
                         |
                         v
                     +-------+
                     |  dlm  |
                     +---+---+
                         |
                         v
                +----------------+
                |pvm-gfs-manager |
                +-------+--------+
                        |
                        v
                   +---------+
                   |   GFS   |
                   | Mounted |
                   +----+----+
                        |
                        v
              زیرساخت آماده است

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

۹. فاز ۲ — سرویس‌های PVM

پس از رسیدن Cluster به Quorum و در دسترس بودن فضای ذخیره‌سازی اشتراکی GFS، زیرساخت Node آماده میزبانی سرویس‌های واقعی PVM است.

در این مرحله، فاز دوم آغاز می‌شود.

به‌جای مدیریت تک‌تک سرویس‌های PVM، PVM یک Meta-Service ارائه می‌دهد:

pvm.service

رابط مدیریتی توصیه‌شده، خود سرویس pvm است:

systemctl enable pvm
systemctl start pvm
systemctl restart pvm
systemctl stop pvm

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

sballd
plogger
pvm-engine
sabad
...

مدیر سیستم معمولاً با یک سرویس واحد تعامل دارد:

pvm

۱۰. Meta-Service به نام `pvm`

سرویس pvm باید به‌عنوان یک Service-Group یا Meta-Service در نظر گرفته شود، نه به‌عنوان یک سرویس با عملکرد مشخص. هدف آن نمایش وضعیت عملیاتی کل Stack سرویس‌های PVM است.

راه‌اندازی pvm باعث می‌شود سرویس‌های PVM موردنیاز بالا بیایند. همچنین توقف یا راه‌اندازی مجدد pvm یک روش متمرکز برای مدیریت Stack سرویس‌های PVM فراهم می‌کند.

مدل عملیاتی مورد نظر این است:

pvm را راه‌اندازی کن؛ گراف وابستگی سرویس‌ها پیش‌نیازها را مدیریت می‌کند.

۱۱. سرویس‌های مهم PVM

۱۱.۱ سرویس `sballd`

sballd سرویس اصلی مدیریت Hypervisor است. یکی از مهم‌ترین سرویس‌های Stack PVM بوده و در نهایت به آماده بودن زیرساخت پایه وابسته است. به‌ویژه sballd نیاز دارد محیط GFS پایدار و در دسترس باشد.

sballd
  |
  v
GFS required
  |
  v
pvm-gfs-manager
  |
  v
DLM
  |
  v
Quorum
  |
  v
Corosync

۱۱.۲ سرویس `plogger`

plogger قابلیت Logging در PVM را فراهم می‌کند. مدیران سیستم معمولاً نیازی به مدیریت مستقل plogger ندارند؛ این سرویس به‌عنوان بخشی از Stack سرویس pvm راه‌اندازی می‌شود.

۱۱.۳ سرویس `pvm-engine`

pvm-engine موتور Microservice در PVM را فراهم می‌کند. مانند سایر اجزای PVM، از طریق Meta-Service به نام pvm مدیریت می‌شود.

۱۱.۴ سرویس `sabad`

sabad مسئول راه‌اندازی API Gateway است و نقطه ورود برای تعامل API-محور با زیرساخت PVM را فراهم می‌کند.

نمودار Stack سرویس‌های PVM

                     +---------------+
                     | pvm.service   |
                     | Meta-Service  |
                     +-------+-------+
                             |
          +------------------+------------------+
          |                  |                  |
          v                  v                  v
     +---------+        +---------+       +------------+
     | sballd  |        | plogger |       | pvm-engine |
     |Hypervisor|       | Logging |       | Microservice|
     +---------+        +---------+       +------------+
          |
          v
     +---------+
     |  sabad  |
     | API GW  |
     +---------+

۱۲. تغییر مهم در PVM نسخه ۷.۱

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

یک تغییر عملیاتی مهم در PVM نسخه ۷.۱ معرفی شد.

نسخه‌های قبل از ۷.۱

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

در نسخه‌های قبل از ۷.۱، راه‌اندازی مجدد Stack سرویس PVM باید به‌عنوان یک عملیات بالقوه مخرب در نظر گرفته شود. مدیران سیستم باید از راه‌اندازی مجدد سرویس‌های مرتبط، به‌ویژه روی Nodeهایی که ماشین‌های مجازی فعال دارند، خودداری کنند.

نسخه ۷.۱ و بالاتر

از PVM نسخه ۷.۱ به بعد، این رفتار تغییر کرده است. راه‌اندازی مجدد Stack سرویس PVM نسبت به ماشین‌های مجازی ایمن است؛ یعنی راه‌اندازی مجدد سرویس‌های PVM دیگر باعث Unload شدن یا خاموش شدن ماشین‌های مجازی نمی‌شود.

بنابراین در PVM نسخه ۷.۱ و بالاتر، Stack سرویس را می‌توان به‌طور عادی مدیریت کرد:

systemctl restart pvm

نسخه PVM	راه‌اندازی مجدد سرویس‌های PVM
`< 7.1`	بالقوه مخرب؛ ممکن است ماشین‌های مجازی Unload یا خاموش شوند
`>= 7.1`	ایمن؛ راه‌اندازی مجدد سرویس‌ها باعث Unload یا خاموش شدن ماشین‌های مجازی نمی‌شود

۱۳. مدل عملیاتی در PVM نسخه ۷.۱ و بالاتر

پس از بوت، سرویس‌های زیرساختی به ترتیب زیر برقرار می‌شوند:

Network → Cluster → Quorum → DLM → GFS

پس از برآورده شدن این پیش‌نیازها، Stack سرویس PVM راه‌اندازی می‌شود:

pvm
 |
 +-- sballd
 +-- plogger
 +-- pvm-engine
 +-- sabad
 +-- سایر سرویس‌های PVM

مدیر سیستم نیازی به راه‌اندازی دستی هر جزء یا بررسی مکرر Stack زیرساخت ندارد. زنجیره وابستگی این دانش را در systemd کدگذاری کرده است.

۱۴. مدیریت توصیه‌شده

برای PVM نسخه ۷.۱ و بالاتر، مدیران سیستم باید به‌طور کلی از Meta-Service به نام pvm برای مدیریت Stack سرویس استفاده کنند.

عملیات معمول:

systemctl enable pvm
systemctl start pvm
systemctl restart pvm
systemctl stop pvm

اگر Node نیاز به فضای ذخیره‌سازی اشتراکی GFS دارد، GFS Manager نیز باید فعال شود:

systemctl enable pvm-gfs-manager

سرویس‌های منفرد تنها در موارد Troubleshooting، Debug یا عملیات نگهداری خاص باید به‌صورت مستقیم مدیریت شوند. در عملکرد عادی، pvm باید به‌عنوان رابط اصلی مدیریتی Stack سرویس PVM در نظر گرفته شود.

۱۵. جمع‌بندی

معماری سرویس‌های PVM به دو لایه اصلی تقسیم می‌شود.

لایه زیرساخت محیط موردنیاز PVM را برقرار می‌کند:

sbone → corosync → quorum → pvm-wait-for-quorum → dlm → pvm-gfs-manager → GFS

لایه سرویس‌های PVM از طریق Meta-Service به نام pvm مدیریت می‌شود:

pvm
 |
 +-- sballd
 +-- plogger
 +-- pvm-engine
 +-- sabad
 +-- سایر سرویس‌های PVM

با وجود این وابستگی‌ها، مدیران سیستم معمولاً تنها نیاز دارند سرویس pvm را فعال کنند. اگر Node نیاز به فضای ذخیره‌سازی اشتراکی GFS داشته باشد، pvm-gfs-manager نیز باید فعال شود. زنجیره وابستگی سرویس‌ها تضمین می‌کند که زیرساخت موردنیاز به ترتیب صحیح راه‌اندازی شده و سرویس‌های PVM تنها زمانی شروع به کار کنند که پیش‌نیازهایشان آماده باشند.

در PVM نسخه ۷.۱ و بالاتر، راه‌اندازی مجدد سرویس‌ها نسبت به ماشین‌های مجازی در حال اجرا نیز ایمن است و systemctl restart pvm یک عملیات عادی و بی‌خطر محسوب می‌شود.

۱. مرور کلی​

۲. مدل راه‌اندازی دو فازی​

۳. سرویس‌های زیرساختی​

۳.۱ سرویس sbone​

۴. سرویس corosync — عضویت در Cluster و Quorum​

۵. سرویس pvm-wait-for-quorum​

۵.۱ هدف​

۵.۲ چرا DLM نمی‌تواند پیش از Quorum راه‌اندازی شود​

۵.۳ دروازه Quorum​

۶. سرویس dlm — Distributed Lock Manager​

۷. سرویس pvm-gfs-manager — مدیریت GFS​

۸. زنجیره کامل زیرساخت​

۹. فاز ۲ — سرویس‌های PVM​

۱۰. Meta-Service به نام pvm​

۱۱. سرویس‌های مهم PVM​

۱۱.۱ سرویس sballd​

۱۱.۲ سرویس plogger​

۱۱.۳ سرویس pvm-engine​

۱۱.۴ سرویس sabad​

نمودار Stack سرویس‌های PVM​

۱۲. تغییر مهم در PVM نسخه ۷.۱​

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

۱۳. مدل عملیاتی در PVM نسخه ۷.۱ و بالاتر​

۱۴. مدیریت توصیه‌شده​

۱۵. جمع‌بندی​