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

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

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

برای راه‌اندازی CEPH باید کلاستری ایجاد کرد که شامل تعدادی 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 انجام می‌شود. این موضوع در شکل زیر نشان داده شده است:

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

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

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

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

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

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

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

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

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

تغییر Host File:

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

/etc/hosts
10.11.12.250 controller102
10.11.12.100 server1
10.11.12.101 server2
10.11.12.102 server3
10.11.12.103 server4

می‌توانید خط اول را کامنت کنید تا 127.0.0.1 همواره به نام سرور 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

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