بلاگ/استفاده از Ceph RBD به‌عنوان بک‌اند ذخیره‌سازی برای ماشین‌های مجازی KVM روی سرور اختصاصی
به‌روز شده

استفاده از Ceph RBD به‌عنوان بک‌اند ذخیره‌سازی برای ماشین‌های مجازی KVM روی سرور اختصاصی

1405/06/140 بازدید
استفاده از Ceph RBD به‌عنوان بک‌اند ذخیره‌سازی برای ماشین‌های مجازی KVM روی سرور اختصاصی

استفاده از Ceph RBD به‌عنوان بک‌اند ذخیره‌سازی برای ماشین‌های مجازی KVM روی سرور اختصاصی

وقتی چند میزبان KVM دارید، نگهداری دیسک ماشین‌های مجازی روی فضای محلی هر سرور محدودیت مهمی ایجاد می‌کند: ماشین مجازی به همان میزبان وابسته می‌ماند. مهاجرت زنده، جابه‌جایی بار و بازیابی سرویس پس از خرابی میزبان نیز به کپی‌کردن دیسک یا استفاده از یک فضای ذخیره‌سازی مشترک نیاز پیدا می‌کند. Ceph RBD این مسئله را با ارائه دیسک‌های بلوکی توزیع‌شده حل می‌کند. هر RBD Image از دید QEMU مانند یک دیسک است، اما داده‌های آن میان OSDهای کلاستر Ceph توزیع و بر اساس سیاست Pool تکثیر یا کدگذاری می‌شود. در این راهنما، Ceph RBD برای ذخیره‌سازی KVM را از ساخت Pool تا اتصال دیسک به ماشین مجازی با libvirt پیکربندی می‌کنیم. نمای معماری اتصال میزبان KVM به کلاستر Ceph RBD

پیش‌نیازها و معماری نمونه

فرض می‌کنیم کلاستر Ceph از قبل نصب شده و وضعیت آن سالم است؛ در صورت نیاز به مرور مراحل ساخت چنین کلاستری، راه‌اندازی کلاستر Ceph با Cephadm روی سرور اختصاصی را ببینید. همچنین یک یا چند سرور اختصاصی به‌عنوان میزبان مجازی‌سازی دارید که روی آن‌ها KVM/QEMU و libvirt اجرا می‌شود. در مثال‌های این مقاله از نام‌ها و آدرس‌های زیر استفاده می‌کنیم: - نام Pool در Ceph: kvm - کاربر cephx: client.libvirt - نام Storage Pool در libvirt: ceph-rbd - آدرس مانیتورهای Ceph: 10.10.10.11، 10.10.10.12 و 10.10.10.13 - نام ماشین مجازی نمونه: vm01 - نام دیسک RBD: vm01-root دستورهای مدیریتی Ceph را روی یک گره دارای دسترسی مدیر اجرا کنید. دستورهای virsh و نصب بسته‌ها باید روی هر میزبان KVM که قرار است به RBD دسترسی داشته باشد اجرا شوند. قبل از شروع، سلامت کلاستر را بررسی کنید:

ceph -s
ceph health detail

بهتر است خروجی ceph -s وضعیت HEALTH_OK را نشان دهد. اگر کلاستر در حال بازیابی، پرکردن OSDها یا رفع ناسازگاری است، ابتدا همان مشکل را بررسی کنید؛ افزودن بار ماشین‌های مجازی می‌تواند عملیات بازیابی را کندتر کند. میزبان‌های KVM باید بتوانند از طریق شبکه به MONها و OSDهای Ceph متصل شوند. در نسخه‌های جدید Ceph، معمولاً پورت‌های 3300 و 6789 برای مانیتورها و بازه 6800:7568 برای OSDها مطرح است. قوانین دقیق فایروال را با نسخه Ceph و تنظیمات شبکه کلاستر خود تطبیق دهید؛ برای نوشتن این قوانین روی سرور لینوکس می‌توانید از راه‌اندازی فایروال nftables روی سرور لینوکس کمک بگیرید.

چرا RBD برای دیسک ماشین مجازی مناسب است؟

RBD یا RADOS Block Device فضای بلوکی را روی RADOS ارائه می‌کند. QEMU می‌تواند با کتابخانه librbd مستقیماً به این فضا متصل شود؛ بنابراین لازم نیست RBD Image را روی میزبان mount کنید یا آن را ابتدا به یک Block Device محلی نگاشت دهید. مقایسه گزینه‌های رایج برای دیسک KVM چنین است:

روش ذخیره‌سازیدسترسی مشترک میان میزبان‌هامهاجرت زندهافزونگی داخلیپیچیدگی عملیاتی
فایل qcow2 روی دیسک محلیخیرمحدودوابسته به RAID میزبانکم
NFSبلهبلهوابسته به معماری NFSمتوسط
iSCSIبلهبلهوابسته به Storage Arrayمتوسط
Ceph RBDبلهبلهبله، در سطح Cephبیشتر

RBD برای محیطی مناسب است که چند میزبان مجازی‌سازی، نیاز به رشد تدریجی ظرفیت و تحمل خرابی دیسک یا گره ذخیره‌سازی دارد. در مقابل، برای یک میزبان KVM کوچک، هزینه نگهداری کلاستر Ceph ممکن است از مزیت آن بیشتر باشد.

نصب ابزارهای لازم روی میزبان KVM

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

sudo apt update
sudo apt install -y qemu-system-x86 libvirt-daemon-system \
  libvirt-clients ceph-common

در توزیع‌های مبتنی بر RHEL نام بعضی بسته‌ها متفاوت است:

sudo dnf install -y qemu-kvm libvirt virt-install ceph-common
sudo systemctl enable --now libvirtd

نام سرویس libvirt ممکن است بر اساس نسخه توزیع libvirtd یا مجموعه‌ای از daemonهای ماژولار مانند virtqemud باشد. برای مرور کامل‌تر نصب و راه‌اندازی خود KVM، نصب KVM در سرور لینوکس CentOS 7 را ببینید. فایل پیکربندی Ceph و اطلاعات مانیتورها باید روی میزبان موجود باشد. روش رایج، قرار دادن فایل در مسیر زیر است:

/etc/ceph/ceph.conf

برای آزمایش ارتباط، دستور زیر را روی میزبان KVM اجرا کنید:

ceph -s

این آزمایش ممکن است فعلاً با هویت مدیریتی انجام شود، اما QEMU نباید برای کار روزمره از کلید مدیر Ceph استفاده کند. در مرحله بعد یک کاربر محدود می‌سازیم.

ساخت Pool مخصوص دیسک‌های KVM

ابتدا یک Pool برای ماشین‌های مجازی ایجاد کنید. مقدار Placement Group یا PG به تعداد OSDها، نسخه Ceph و فعال‌بودن autoscaler بستگی دارد. در کلاسترهای جدید می‌توان Pool را با تعداد اولیه کم ساخت و مدیریت PG را به autoscaler سپرد:

ceph osd pool create kvm 32
ceph osd pool application enable kvm rbd
ceph osd pool set kvm pg_autoscale_mode on
rbd pool init kvm

نام Pool را جدا از Poolهای CephFS یا Object Storage انتخاب کنید. این جداسازی اعمال سیاست ظرفیت، سهمیه، نوع افزونگی و پایش مصرف ماشین‌های مجازی را ساده‌تر می‌کند. اگر Pool از نوع replicated است، اندازه تکرار را متناسب با تعداد گره‌ها و Failure Domain تعیین کنید. برای نمونه:

ceph osd pool set kvm size 3
ceph osd pool set kvm min_size 2

این مقادیر را کورکورانه روی کلاستر تک‌گره یا دوگره اعمال نکنید. مقدار size باید با توپولوژی CRUSH و تعداد Failure Domainهای واقعی سازگار باشد.

ساخت کاربر cephx با دسترسی محدود

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

ceph auth get-or-create client.libvirt \
  mon 'profile rbd' \
  osd 'profile rbd pool=kvm'

برای اطمینان از ثبت مجوزها:

ceph auth get client.libvirt

خروجی شامل یک کلید محرمانه است. آن را در لاگ، مخزن Git یا متن تعریف ماشین مجازی قرار ندهید. libvirt این کلید را در Secret Store خود نگهداری می‌کند. برای آزمایش هویت ساخته‌شده می‌توانید کلید را موقتاً در فایلی با دسترسی محدود قرار دهید:

sudo ceph auth get client.libvirt \
  -o /etc/ceph/ceph.client.libvirt.keyring
sudo chmod 600 /etc/ceph/ceph.client.libvirt.keyring
sudo rbd -n client.libvirt pool ls

پس از تأیید اتصال، استفاده QEMU از کلید از طریق libvirt Secret انجام می‌شود.

ثبت کلید Ceph در libvirt

ابتدا یک UUID بسازید:

uuidgen

فرض می‌کنیم خروجی این دستور مقدار زیر باشد:

11111111-2222-3333-4444-555555555555

یک فایل به نام ceph-secret.xml بسازید:

<secret ephemeral='no' private='no'>
  <uuid>11111111-2222-3333-4444-555555555555</uuid>
  <usage type='ceph'>
    <name>client.libvirt secret</name>
  </usage>
</secret>

Secret را تعریف کنید:

sudo virsh secret-define --file ceph-secret.xml

سپس مقدار خام کلید را از Ceph دریافت و بدون چاپ اضافه به libvirt منتقل کنید:

ceph auth get-key client.libvirt | \
  sudo virsh secret-set-value \
  --secret 11111111-2222-3333-4444-555555555555 \
  --base64

گزینه --base64 در این فرمان به این معناست که ورودی، همان کلید base64 تولیدشده توسط Ceph است. UUID و نام کاربری Ceph را برای مرحله تعریف Storage Pool نگه دارید.

تعریف Storage Pool نوع RBD در libvirt

فایل ceph-rbd-pool.xml را با محتوای زیر آماده کنید:

<pool type='rbd'>
  <name>ceph-rbd</name>
  <source>
    <name>kvm</name>
    <host name='10.10.10.11' port='3300'/>
    <host name='10.10.10.12' port='3300'/>
    <host name='10.10.10.13' port='3300'/>
    <auth username='libvirt' type='ceph'>
      <secret uuid='11111111-2222-3333-4444-555555555555'/>
    </auth>
  </source>
</pool>

در username پیشوند client. نوشته نمی‌شود؛ libvirt آن را به هویت Ceph اضافه می‌کند. پورت و آدرس مانیتورها را نیز از تنظیمات واقعی کلاستر بگیرید. اگر MONها با Ceph Messenger v1 در دسترس هستند، ممکن است لازم باشد به‌جای 3300 از 6789 استفاده کنید. Pool را تعریف، راه‌اندازی و برای شروع خودکار فعال کنید:

sudo virsh pool-define ceph-rbd-pool.xml
sudo virsh pool-start ceph-rbd
sudo virsh pool-autostart ceph-rbd
sudo virsh pool-info ceph-rbd
sudo virsh vol-list ceph-rbd

اگر vol-list بدون خطای احراز هویت اجرا شد، ارتباط libvirt با Ceph برقرار است.

ساخت RBD Image برای دیسک ماشین مجازی

یک دیسک ۸۰ گیگابایتی بسازید:

rbd create kvm/vm01-root --size 80G
rbd info kvm/vm01-root

ویژگی‌های RBD باید با نسخه QEMU و Ceph میزبان‌ها سازگار باشند. قابلیت‌هایی مانند layering برای snapshot و clone مفیدند و exclusive-lock پیش‌نیاز بعضی قابلیت‌های پیشرفته‌تر است. قابلیت‌های Image را بررسی کنید:

rbd info kvm/vm01-root

اگر همه میزبان‌ها نسخه‌های جدید و هماهنگ دارند، می‌توانید قابلیت‌های مورد نیاز را هنگام ساخت مشخص کنید. فعال‌کردن قابلیت ناشناخته برای QEMU قدیمی باعث می‌شود دیسک باز نشود؛ بنابراین پیش از تغییر، سازگاری نسخه‌ها را بسنجید.

اتصال دیسک RBD به ماشین مجازی

برای افزودن دیسک به vm01، بخش زیر را در تعریف XML ماشین و داخل عنصر devices قرار دهید:

<disk type='network' device='disk'>
  <driver name='qemu' type='raw' cache='none' io='native'/>
  <auth username='libvirt'>
    <secret type='ceph'
            uuid='11111111-2222-3333-4444-555555555555'/>
  </auth>
  <source protocol='rbd' name='kvm/vm01-root'>
    <host name='10.10.10.11' port='3300'/>
    <host name='10.10.10.12' port='3300'/>
    <host name='10.10.10.13' port='3300'/>
  </source>
  <target dev='vdb' bus='virtio'/>
</disk>

تعریف ماشین را ویرایش کنید:

sudo virsh edit vm01

پس از راه‌اندازی یا راه‌اندازی مجدد ماشین، دیسک باید در سیستم‌عامل مهمان به شکل دستگاهی مانند /dev/vdb دیده شود. داخل مهمان می‌توانید آن را بررسی کنید:

lsblk

برای دیسک داده، سپس جدول پارتیشن و فایل‌سیستم مناسب بسازید. مطمئن شوید دیسکی را فرمت می‌کنید که تازه اضافه شده است؛ انتخاب اشتباه دستگاه می‌تواند داده‌های سیستم‌عامل را از بین ببرد. مسیر داده هنگام خواندن و نوشتن دیسک ماشین مجازی KVM روی RBD Image و OSDهای کلاستر Ceph

نکات کارایی و پایداری

شبکه Ceph مستقیماً بر تأخیر دیسک ماشین مجازی اثر دارد. برای بارهای حساس، شبکه‌ای با ظرفیت و تأخیر مناسب در نظر بگیرید و ترافیک ذخیره‌سازی را زیر نظر بگیرید. جداسازی ترافیک عمومی ماشین‌ها از ترافیک Ceph می‌تواند ازدحام را کاهش دهد، اما طراحی دقیق آن به توپولوژی شبکه بستگی دارد. تنظیماتی مانند بهینه‌سازی شبکه سرور لینوکس با TCP BBR و sysctl نیز می‌تواند به کاهش تأخیر مسیر شبکه کمک کند. تنظیم cache='none' معمولاً انتخاب قابل پیش‌بینی‌تری برای دیسک RBD است، زیرا از دوباره‌کش‌شدن داده در Page Cache میزبان جلوگیری می‌کند. با این حال، تنظیمات cache و I/O را باید با بار واقعی، نسخه QEMU و نیاز به تضمین ثبت داده آزمایش کرد. این موارد را نیز در برنامه عملیاتی قرار دهید: - فضای آزاد OSDها و نزدیک‌شدن Pool به آستانه‌های nearfull و full را پایش کنید. - ساعت همه میزبان‌ها و گره‌های Ceph را با NTP یا Chrony همگام نگه دارید. - پیش از مهاجرت زنده، دسترسی میزبان مقصد به MONها، Secret یکسان و نسخه‌های سازگار QEMU را بررسی کنید. - از snapshot به‌عنوان جایگزین پشتیبان‌گیری استفاده نکنید؛ snapshot نقطه بازیابی کوتاه‌مدت است و با خرابی کل کلاستر از بین می‌رود. - برای دیسک‌های حساس، سازگاری فایل‌سیستم یا برنامه با snapshot را در نظر بگیرید؛ snapshot بدون هماهنگی معمولاً crash-consistent است، نه application-consistent.

عیب‌یابی خطاهای رایج

خطای RADOS permission denied معمولاً از نام کاربری، Secret یا مجوز cephx می‌آید. خروجی این فرمان‌ها را بررسی کنید:

ceph auth get client.libvirt
sudo virsh secret-list
sudo virsh pool-dumpxml ceph-rbd

خطای timeout بیشتر به مسیر شبکه، DNS، پورت مانیتورها یا دسترسی به OSDها مربوط است. برقراری اتصال به MON کافی نیست؛ QEMU پس از دریافت نقشه کلاستر باید به OSDهای نگهدارنده داده نیز دسترسی داشته باشد. اگر QEMU از یک قابلیت RBD پشتیبانی نکند، در لاگ libvirt یا QEMU خطایی درباره unsupported feature دیده می‌شود. اطلاعات Image و نسخه بسته‌ها را مقایسه کنید:

rbd info kvm/vm01-root
qemu-system-x86_64 --version
ceph --version

برای مشاهده خطاهای میزبان نیز از journal استفاده کنید:

sudo journalctl -u libvirtd --since "30 minutes ago"

در سیستم‌های دارای daemon ماژولار، نام سرویس را با virtqemud جایگزین کنید.

جمع‌بندی

راه‌اندازی Ceph RBD برای ذخیره‌سازی KVM چهار بخش اصلی دارد: ساخت Pool مخصوص RBD، تعریف کاربر محدود cephx، ثبت کلید در libvirt و اتصال RBD Image به ماشین مجازی. پس از آن، میزبان‌های KVM می‌توانند بدون نگهداری فایل دیسک روی فضای محلی، به دیسک مشترک ماشین دسترسی داشته باشند. مزیت این معماری زمانی روشن‌تر می‌شود که چند میزبان مجازی‌سازی دارید و به مهاجرت ماشین‌ها، افزایش ظرفیت ذخیره‌سازی و تحمل خرابی نیاز دارید. در عوض، سلامت شبکه و Ceph به بخشی از مسیر حیاتی I/O تبدیل می‌شود و باید مانند خود میزبان‌های مجازی‌سازی پایش شود. اگر برای استقرار KVM و اتصال آن به کلاستر Ceph به منابع پردازشی اختصاصی نیاز دارید، مشخصات و گزینه‌های قابل ارائه را در صفحه سرور اختصاصی آریاسرویس بررسی کنید.