راه اندازی یک Share Storage به کمک CEPH برای زیرساخت ابری در Ubuntu 16.04 – بخش دوم

۱۹ دی ۱۳۹۶
سف چیست

در قسمت اول، در خصوص Ceph و مقایسه ی آن با راه‌کارهای سخت افزاری به صورت مفصل صحبت کردیم. در قسمت دوم قصد داریم با نیازمندی‌های اولیه برای راه‌اندازی سف آشنا شویم و مقدمات ایجاد یک کلاستر را هم فراهم کنیم. باز هم باید تاکید کنیم که بسیاری از کسب‌وکارهای موفق در دنیا و حتی در ایران (که مسلما شما نیز از سرویس‌های آنها استفاده کرده‌اید) هم‌اکنون از این راه‌کار استفاده می‌کنند. بنابراین سف در صورتی که به صورت درست کانفیگ و نگه‌داری شود، راه حلی بسیار ارزان‌قیمت و حرفه‌ای برای زیرساخت ذخیره‌سازی شما خواهد بود.

قبل از هر کاری ابتدا باید با ساختار Ceph آشنا شویم. همان‌طور که قبلا توضیح داده شد، سف امکان راه‌اندازی Object Storage، Block Storage و  Share File System را در اختیار ما قرار می‌دهد. در شکل زیر این موضوع نشان داده شده است.

سف چیست

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

  • Ceph Monitor

سف مانیتور وطیفه‌ی مانیتور کردن وضعیت کلاستر و بالا نگه داشتن آن را برعهده دارد. نقشه و یا Cluster map هر کلاستر نیز در اختیار مانیتور قرار دارد که هر کلاینت و یا CEPH Node نقشه‌ی کلاستر را از این نودهای مانیتورینگ می‌گیرد. در واقع به کمک این نقشه می‌توان از وضعیت دیسک‌ها و محل قرارگیری آنها مطلع شد. در ادامه و در هنگام راه‌اندازی سف گفته خواهد شد که بهتر است در هر کلاستر سه سرور نقش مانیتورینگ را بر عهده داشته باشد که در صورت از دست رفتن یک سرور، کلاستر Down نشود و دسترسی به داده‌ها به صورت موقت از دست نرود. هر چند در کلاسترهای بزرگ توصیه اکید می‌شود ۵ نود برای این کار در نظر گرفته بشود و به کار بردن بیشتر از ۵ نود نیز دلیل موجهی نخواهد داشت.

  • Ceph OSD

OSD  وظیفه‌ی چک کردن خود و دیگر OSD ها را برعهده دارد. در واقع به کمک همین سیستم است که نیاز به یک نود مرکزی وجود ندارد و تمامی دیسک‌ها در لحظه از وضعیت یکدیگر اطلاع دارند. OSD یا Object Storage Daemon در عمل به هر دیسک فیزیکی روی یک سرور گفته می‌شود و CEPH -OSD وظیفه‌ی ذخیره‌سازی داده‌ها بر روی دیسک‌های لوکال و فراهم کردن امکان دسترسی به آنها از طریق شبکه را برعهده دارد.

Ceph چگونه داده‌ها را ذخیره می‌کند؟

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

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

سف اطلاعات واقعی را در Object به صورت فلت ذخیره می‌کند که شامل ۳ بخش زیر است:

از اطلاعات ID و Metadata در موارد مختلفی مانند ذخیره‌سازی attributes در CephFS استفاده می‌شود.

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

در کلاسترهای بزرگ که شامل میلیون‌ها Obecjt است، نگه‌داری و مدیریت این تعداد Object و پیدا کردن آن‌ها در لحظه سخت می‌شود. به همین دلیل مفهومی به نام PG یا Placement Group تعریف شده است که Object های مرتبط با یک Pool را در یک PG نگه‌داری می‌کند. Map کردن این موارد به یکدیگر توسط الگوریتم CRUSH انجام می‌شود. این موضوع در شکل زیر نشان داده شده است:

ceph placement group

بنابر این هر Object در چند PG مختلف قرار می‌گیرد. اینکه در تصویر فوق هر PG به دو و یا سه OSD متصل شده است، مربوط به کانفیگ ما در انتخاب Replica می‌شود. فراموش نکنید که در ادامه و هنگام تعریف Pool باید تعداد PG را نیز مشخص کنیم. این که تعداد PG چه قدر باید باشد، در ادامه بررسی خواهد شد. این ها همه جزو مواردی هستند که در کانفیگ مناسب و حرفه‌ای سف و در نتیجه نحوه ی عملکرد آن تاثیر می‌گذارند.

ceph pool

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

راه‌اندازی اولیه Ceph

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

مورد بعدی حداقل تعداد نودهای مانیتورینگ برای شکل  دادن Quorum است. برای شکل گرفتن Quorum و در نتیجه بالا آمدن سف، همواره باید حداقل نصف + ۱ مانیتورنگ نود بالا باشد. برای همین همواره تعداد نودها در کلاسترینگ فرد در نظر گرفته می‌شود. به عنوان مثال در صورتی که ۳ مانیتورینگ نود برای کلاستر در نظر بگیریم، همیشه بایدسرویس مانتیورینگ بر روی نصف + ۱ سرور که می‌شود ۲، بالا باشد. یعنی در واقع شما فقط می‌توانید در لحظه یک سرور را از مدار خارج کنید، بدون اینکه دچار مشکل شوید. در محیط‌های واقعی توصیه می‌شود تعداد نود های مانیتورینگ پنج عدد باشد که در صورت از دست رفتن ۲ نود مانیتورینگ، اتفاقی برای کلاستر سف نیفتد و به صورت موقت هم دسترسی به داده‌ها از دست نرود.

برای نود های OSD نیز محدودیتی به صورت کلی وجود ندارد. شما می‌توانید سرورهای مختلف با تعداد متفاوت دیسک فیزیکی را وارد کلاستر سف کنید تا بتوانید از مجموعه ظرفیت این دیسک‌ها استفاده نمایید. البته برای کارایی بالاتر بهتر است تعداد دیسک‌های هر سرور  را تا حد امکان بالاتر در نظر بگیرید. به عنوان مثال کارایی ۵ سرور با ۱۰ دیسک روی هرکدام بالاتر از ۱۰ سرور با ۵ دیسک روی هرکدام است. البته نکات زیادی در این زمینه دخیل است و به تنهایی نمی توان این گذاره را درست در نظر گرفت. ولی در حالت کلی تعداد دیسک‌های بیشتر روی هر سرور کارایی را افزایش خواهد داد.

ما در این سناریو ۴ سرور خواهیم داشت که ۳ تا از این سرورها نقش مانیتورینگ را برعهده دارد و هر ۴ سرور نقش OSD را نیز خواهد داشت. بر روی هر سرور نیز دو هارد قرار دارد. همچنین این سناریو بر روی Ubuntu 16.04 راه‌اندازی خواهد شد.

سناریو سف

سف یک ابزار کارامد به نام ceph deploy دارد که ما را قادر می‌سازد به راحتی کلاستر خود را بالا آروده و OSD جدیدی به آن اضافه و یا کم کنیم. ما در این سناریو از این ابزار برای راه‌اندازی اولیه کمک خواهیم گرفت. در بخش‌های بعدی ممکن است برای کارهای خاص از دستورات دیگری استفاده کنیم. برای استفاده از ceph deploy بهتر است یک سرور جدا از سرورهای فوق را انتخاب کنید و به کمک آن کلاستر خود را توسعه دهید.

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

تغییر Host File:

تمامی نودها باید بتوانند همدیگر را با اسم ببینیند. بنابراین اولین قدم تنظیم Host File است.

/etc/hosts
۱۰٫۱۱٫۱۲٫۲۵۰ controller102
۱۰٫۱۱٫۱۲٫۱۰۰ server1
۱۰٫۱۱٫۱۲٫۱۰۱ server2
۱۰٫۱۱٫۱۲٫۱۰۲ server3
۱۰٫۱۱٫۱۲٫۱۰۳ server4

می‌توانید خط اول را کامنت کنید تا ۱۲۷٫۰٫۰٫۱ همواره به نام سرور Resolve شود و نه به localhost.

نصب Time Server:

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

apt-get install chrony

در این سناریو سروری که به عنوان ceph deploy در نظر گرفته شده است، به عنوان تایم سرور اصلی نیز در نظر گرفته شده است. بنابراین بر روی هر ۴ سرور دیگر که قرار است در کلاستر سف باشد، تنظیمات را به شکل زیر تغییر می‌دهید:

sed -i "s/server/#server/g" /etc/chrony/chrony.conf
echo server CEPH-DEPLOY-IP iburst >> /etc/chrony/chrony.conf
service chrony restart

فراموش نکنید متغییر CEPH-DEPLOY-NODE را با ادرس مناسب جایگزین کنید. برای مشاهده ی نتیجه نیز از دستور chrony sources استفاده کنید.

نصب سایر پکیج‌ها:

اگر مثل ما برای این سناریو از محیط مجازی شده VMWare استفاده می‌کنید حتما VMWare Tools را نصب کنید.

apt-get install -y open-vm-tools

همچنین پایتون را نیز نصب کنید.

apt-get install -y python python-pip

تنظیم SSH:

در این مرحله باید تنها بر روی نودی که به عنوان ceph deploy در نظر گرفته شده است، تنظیماتی انجام دهیم تا بتواند بدون نیاز به پسورد به ۴ نود دیگر SSH بزند. در ادامه روال کار مشخص شده است.


ssh-keygen

vim ~/.ssh/config


Host server1
Hostname 10.11.12.100
Port 22
User root
Host server2
Hostname 10.11.12.101
port 22
User root
Host server3
Hostname 10.11.12.102
port 22
User root
Host server4
Hostname 10.11.12.103
port 22
User root
ssh-copy-id server1
chmod 644 ~/.ssh/config
ssh-copy-id server2
ssh-copy-id server3
ssh-copy-id server4

برای تست باید بتوانید از روی ceph deploy به هر ۴ سرور دیگر SSH بزنید، بدون آنکه از شما سوالی در خصوص نام کاربری و یا پسورد بپرسد.

ssh server1

آماده کردن دیسک‌ها:

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

cfdisk /dev/sdb
mkfs.xfs -f /dev/sdb

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

4 ديدگاه
برچسب‌ها:
  • sd گفت:

    سلام
    خیلی ممنون هر دو بخش خیلی اموزش های خوبی بودند.
    بخش سوم رو کی می ذارید؟ 🙂

  • محمدعرفان شمسی گفت:

    سلام
    ممنون از توجه شما. بخش جدید اضافه شده است.

  • علیرضا گفت:

    سلام
    توی سف میشه از Storage Device ها هم استفاده کرد یا فقط مختص سرورهای فیزیکی هستند.

  • شما باید سرور های فیزیکی رو مدیریت و پکیج ها رو بر روی اون نصب کنید. حالا دیسک های بر روی هر سرور اگر می خواهید روی یک device مانند san باشند فرقی برای سف نمی کند. می تونید چندین pool مختلف بر روی san ایجاد و هر کدام را به عنوان یک دیسک به سیستم عامل معرفی کنید و بعد از طریق سف از آنها استفاده کنید.

  • × برای اطلاع از آخرین اخبار و مقالات آروان عضو خبرنامه ما شوید