مشتریانی که از پایگاه داده اوراکل استفاده میکنند نیازهایی مانند SLAهای دقیق، عملکرد ثابت و دسترسیپذیری بالا دارند. مدیریت ذخیرهسازی دادهها در چنین محیطهایی به دلیل وجود این الزامات میتواند تبدیل به چالش بزرگی شود. مسائل رایج در استفاده از راه حلهای ذخیرهسازی سنتی برای برنامههای کاربردی مهم تجاری عبارتست از ناتوانی در افزایش و کاهش مقیاس، ناکارآمدی ذخیرهسازی، مدیریت پیچیده و هزینههای بالای عملیاتی VMware vSAN به طور گستردهای به عنوان یک راه حل زیرساخت فراهمگرا (HCI) به کار گرفته شده است و یک ذخیرهسازی مقیاسپذیر، انعطافپذیر و با کارایی بالا را با استفاده از سختافزار مقرونبهصرفه فراهم میکند. vSAN از مدیریت مبتنی بر سیاست ذخیرهسازی استفاده میکند، که گردش کار پیچیده مدیریتی را که در سیستمهای ذخیرهسازی سنتی سازمانی با توجه به پیکربندی و خوشهبندی وجود دارد، ساده و خودکار میکند. در این مقاله بهبود مستمر در نرمافزار VMware vSAN را بررسی خواهیم کرد.
مرور راه حل
این راه حل به چالشهای تجاری متداول سازمانها در محیط پردازش معاملات آنلاین (OLTP) که نیاز به عملکرد قابل پیشبینی دارد میپردازد. این راه حل به مشتریان کمک میکند تا پیکربندیهای بهینه مخصوص پایگاه داده Oracle 12c را در vSAN 6.7 طراحی و پیادهسازی کنند.
نکات برجسته کلیدی
نکات زیر تایید میکند که vSAN یک راه حل ذخیرهسازی در کلاس سازمانی است که برای اجرای بارهای سنگین اوراکل مناسب است:
- عملکرد قابل پیش بینی Oracle OLTP در خوشه vSAN تمام فلش
- مدیریت مبتنی بر سیاست ذخیرهسازی (SPBM) برای مدیریت منابع ذخیرهسازی همراه با روش طراحی ساده که پیچیدگی عملیاتی و نگهداری SAN سنتی را حذف میکند.
- پلتفرم انعطافپذیر برای بارهای کاری مهم در سطح ۱
- معماری معتبر که اجرا و خطرات عملیاتی را کاهش میدهد.
فناوریهای مورد استفاده در این راه حل شامل موارد زیر هستند:
- VMware vSphere
- VMware vSAN
- VMware Cloud در AWS
- پایگاه داده اوراکل
- SSD سامسونگ از نوع NVMe
بررسی اجمالی آزمون
این راه حل، عملکرد پایگاه داده اوراکل را که در محیط vSAN اجرا میشود اعتبار میبخشد و آزمایشات انجام شده شامل موارد زیر است:
- Oracle OLTP مانند حجم کار روی یک پایگاه داده بزرگ
- استفاده از مدیریت مبتنی بر سیاست ذخیرهسازی (SPBM) برای ارائه ترکیبی از خط مشی کدگذاری RAID 1 و RAID 5 در Database VM برای دستیابی به تعادل بین کارایی و عملکرد فضای vSAN
- حجم کار با Deduplication و فشردهسازی فعال
- همگامسازی مجدد vSAN در هنگام خرابی میزبان
تست بار کاری واحد Oracle VM
تمرکز این آزمایش بر حجم کار زیاد Oracle OLTP در vSAN بود و از SLOB برای تاکید بر پایگاههایOracle در خوشه vSAN انجام شد. ما انتخاب کردیم که پایگاه داده VM را با ۳۲ کاربر به منظور ایجاد فشردهترین درخواستهای پایگاه داده مورد بررسی قرار دهیم. حجم کار ۶۰ دقیقه طول کشید و با پیکربندیهای مختلف سیاست ذخیرهسازی vSAN آزمایش تکرار شد که آخرین مرحله آن محدود به استفاده از دو VM بود. برای مشاهده نتایج با تنظیمات مختلف، در چهار پیکربندی مختلف یعنی R1، R15، R1+DC و R15+DC آزمایشات تکرار شدند.
نتایج آزمایش و مشاهدات (R1)
ما معیارهای کلیدی برای حجم کار OLTP را اندازهگیری کردیم و پیکربندی R1 را به عنوان عملکرد پایه برای آزمایشهای OLTP مورد مطالعه قرار دادیم. نمودار زیر، IOPS ایجاد شده توسط VMهای پایگاه داده Oracle در طول آزمایش با خط مشیهای مختلف vSAN را نشان میدهد. برای سیاست R1، متوسط IOPS مشاهده شده ۱۰۷۸۰۰ بود. توجه داشته باشید که حجم کار ترکیبی از ۷۰ درصد خواندن و ۳۰ درصد نوشتن بود و تاخیر خواندن و نوشتن در طول اجرا به ترتیب با مقادیر ۱ و ۲ میلیثانیه پایدار شد. این نشان میدهد که vSAN علیرغم شدت زیاد حجم کار و اندازه پایگاه داده، عملکرد قابل اعتمادی را برای یک برنامه مهم تجاری مانند پایگاه داده Oracle ارائه میدهد. IOPS مشاهده شده در سطح VM سرویسگیرنده با خواندن و نوشتن فیزیکی IO در گزارشات AWR پایگاه داده اوراکل مطابقت دارد.
تاخیر در یک آزمون OLTP معیار مهمی برای تعیین میزان کنترل حجم کار است. تاخیر کمتر IO، زمان انتظار CPU برای تکمیل IO را کاهش میدهد و عملکرد برنامه را بهبود میبخشد. همانظور در چارت بالا میبینید میانگین تاخیر خواندن ۱ میلیثانیه و متوسط تاخیر نوشتن ۲ میلیثانیه در طول این سناریوی بار کاری بوده است. پایگاه دادهها در دنیای واقعی که در حالت ثابت کار میکنند، تاخیرهای بسیار کمتری خواهند داشت. میانگین استفاده از CPU در ESXi که پایگاه داده اوراکل را میزبانی میکند در کل حجم کار کمتر از ۴۵ درصد بود.
مقایسه پیکربندی پایه با سایر تنظیمات vSAN
vSAN فناوریهای کاهش داده داخلی شامل کدگذاری، پاک کردن، کپی مجدد و فشردهسازی را ارائه میدهد. برای درک تاثیر عملکرد معرفی شده توسط این ویژگیها، پیکربندی پایه (R1) را با سه پیکربندی دیگر مقایسه کردیم. در پیکربندی R15، ترکیبی از سیاست vSAN RAID 1 mirroring و پاک کردن کد (RAID 5) استفاده شد. دیسک Redo باRAID 1 پیکربندی شده در حالی که سایر دیسکها با RAID 5 پیکربندی شدهاند که باعث ایجاد تعادل بین عملکرد و هزینه میشود. میانگین IOPS از ۱۰۷۰۰۰ به ۸۴۱۰۰ رسید که ۲۱ درصد کاهش داشت. تاخیر خواندن و نوشتن مشاهده شده به ترتیب ۱.۳ و ۳.۸ میلیثانیه بود.
در پیکربندی R1+DC، قابلیت حذف و فشردهسازی vSAN فعال شد. این بار میانگین IOPS با کاهش ۱۵ درصدی به ۹۱۳۰۰ رسید و تاخیر خواندن و نوشتن مشاهده شده به ترتیب ۱.۲ و ۱.۷ میلیثانیه بود.
در پیکربندی R15+DC، از ویژگی کدگذاری پاک کردن (RAID 5) نیز همراه با deduplication و فشردهسازی استفاده شد. در این آزمایش،IOPS مشاهده شده ۶۳۳۰۰ بود که ۴۱ درصد در مقایسه با روش پایه کاهش یافته است. تاخیر خواندن و نوشتن مشاهده شده ۱.۷ و ۴.۷ میلیثانیه بود. این پیکربندی به دلیل کدگذاری پاک شدن و حذف مجدد و فشردهسازی vSAN، بهترین بهرهوری ممکن دیسک را فراهم میکند.
تست مقیاسپذیری حجم کار دو ماشین مجازی Oracle
برای یک سیستم ذخیرهسازی Enterprise با عملکرد خوب، یکی از الزامات اصلی، افزایش حجم کار پایگاه داده با IOPS و کاهش تاخیر است. در این آزمایش، دو بار کاری پایگاه داده به طور همزمان روی vSAN با استفاده از SLOB با تنظیمات مختلف SPBM اجرا شد. یکی از VMها با R1 Storage Policy و دیگری با خط مشیهای ذخیرهسازی R15 پیادهسازی شد. هر دو حجم کار به طور همزمان به مدت ۶۰ دقیقه اجرا شد.
نتایج آزمایش و مشاهدات
در حالی که هر دو حجم کار پایگاه داده به طور همزمان اجرا میشود، متوسط IOPS در خوشه vSAN برابر با ۱۶۹۰۰۰ بود. معیار کلیدی دیگر برای عملکرد OLTP داشتن تاخیر قابل پیشبینی است. در VM با استفاده از سیاست ذخیرهسازی R1، تاخیر خواندن و نوشتن مشاهده شده ۱.۹ و ۱.۱ میلیثانیه بود. در VM با استفاده از سیاست ذخیرهسازی R15، تاخیر خواندن و نوشتن به ۱.۴ و ۴.۳ میلیثانیه رسید.
مقاله پیشنهادی“VMware vSAN چیست؟ ساختار و اجزای آن (قسمت اول)”
vSAN Resiliency and Adaptive Resync
vSAN 6.7 یک ویژگی جدید به نام Adaptive Resync را معرفی میکند که اطمینان میدهد در طول تغییرات بار پویای سیستم، سهم عادلانه منابع برای VM I/O و vSAN Resync I/O در دسترس باشد. هنگامی که فعالیتهای ورودی/خروجی از پهنای باند ارائه شده فراتر میرود، ویژگی Adaptive Resync کنترل عادلانه سطح پهنای باند را تضمین میکند. ما سناریوهای زیر را برای شبیهسازی شکستهای احتمالی دنیای واقعی در طول حجم کار OLTP طراحی کردیم. دو ماشین مجازی VM Oracle Database در این آزمایش استفاده شد و حجم کار SLOB بر روی VMهای پایگاه داده اجرا شد؛ یک بار با استفاده از سیاست ذخیرهسازی R1 و بار دیگر با استفاده از سیاست ذخیرهسازی R15 و در نهایت به عنوان بخشی از این آزمون، سناریوی شکست میزبان را آزمایش کردیم.
نتایج آزمایش و مشاهدات
پس از شکست میزبان، حجم کار SLOB ادامه پیدا کرد و هیچ خطای IO در قطع سیستم عامل لینوکسVM یا Oracle وجود نداشت. به محض فعال کردن گزینه تعمیر فوری اشیا، عملیات همگامسازی مجدد آغاز میشود. ترافیک همگامسازی از ساعت ۲:۵۵ بعد از ظهر آغاز شد. با افزایش حداکثر ترافیک همگام سازی مجدد به ۱.۱۱ گیگابایت بر ثانیه در ساعت ۳:۰۵ بعد از ظهر، افزایش تدریجی مشاهده شد. تنظیمکننده پهنای باند vSAN توان بازیابی IO را بیشتر از پهنای باند تضمین شده تشخیص داد. برای اولویتبندی و تقسیم عادلانه پهنای باند به VM IO، ترافیک بازیابی IO بعد از ساعت ۳:۰۵ بعد از ظهر کاهش یافت و در حد ۲۰ درصد از پهنای باند موجود ثابت ماند. هنگامی که حجم کار اوراکل در ۳:۴۵ بعد از ظهر به پایان رسید،vSAN به طور پویا IO بازیابی را افزایش داد تا از پهنای باند موجود استفاده کند. این آزمایش نشان میدهد که چگونه ویژگیAdynable Resync مهمان را در اولویت قرار میدهد؛ در حالی که در اولین فرصت به vSAN اجازه میدهد تا از حداکثر پهنای باند در طول هرگونه فعالیت مجدد همگامسازی استفاده کند.
نتیجهگیری
vSAN یک پلتفرم HCI مقرون به صرفه و با کارایی بالاست که به سرعت مستقر میشود، مدیریت آن آسان است و به طور کامل با پلتفرم VMware vSphere ادغام میشود. در این معماری مرجع،OLTP سنگین مانند حجم کار را در برابر یک و دو ماشین مجازی پایگاه داده Oracle اجرا کردیم و به ترتیب بیش از ۱۰۸۰۰۰ و۱۶۹۰۰۰ IOPS با تاخیر کم به دست آوردیم. ما همچنین نشان دادیم که چگونه vSAN SPBMامکان کنترل دیسکهای مختلف Oracle Database را فراهم میکند تا بین بهرهوری و عملکرد فضا تعادل ایجاد کند. معماری VMware HCI مجهز به vSAN قادر به اجرای حجم زیاد پایگاه داده OLTP برای سختترین برنامههای تجاری امروزی است.