دیسکهای کند برای سیستمعامل، دیسکهای سریع برای داده
در طول سالها دریافتهام که مردم اغلب به سمت ذخیرهسازی با عملکرد بالا و قابلیت اطمینان بالا برای پارتیشن سیستمعامل کج میروند، اما ذخیرهسازی کند و «مقرونبهصرفه» را برای ذخیرهسازی دادههای حیاتی انتخاب میکنند. از اینکه این اتفاق چقدر زیاد میافتد شگفتزده هستم و اکنون، با ظهور هایپروایزرها، میبینم که همین رفتار در آنجا هم تکرار میشود — و مشکلات قبلاً موجود را مرکب میکند.
در بسیاری از سیستمهای امروزی تنها با یک آرایه ذخیرهسازی مشترک بین تمام اجزای سیستم سروکار داریم. در این موارد با مشکل عدم تعادل عملکرد سیستم ذخیرهسازی مواجه نیستیم. این یکی از مزایای بزرگ این رویکرد است و دلیل اصلی توصیه شدید آن. تمام عملکرد در یک استخر مشترک است و اجزایی که به عملکرد نیاز دارند به آن دسترسی دارند.
در بسیاری از موارد، چه در تلاش برای افزایش طراحی عملکرد یا قابلیت اطمینان یا به دلیل ضرورت فنی، میبینم که افراد آرایههای ذخیرهسازی خود را جدا میکنند و هایپروایزرها و سیستمعاملها را روی یک آرایه و دادهها را روی آرایه دیگری قرار میدهند. اما آنچه شگفتآور است این است که آرایههای اختصاصدادهشده به هایپروایزر یا سیستمعامل اغلب بهطرز گیجکنندهای بزرگ در ظرفیت و بسیار بالا در عملکرد هستند — اغلب شامل اسپیندلهای ۱۵,۰۰۰ دور در دقیقه یا حتی دیسکهای حالت جامد با هزینه زیاد. تقریباً همیشه در RAID 1 (طبق استانداردهای رایج از ۱۹۹۸.)
آنچه باید درک شود این است که سیستمعاملها خودشان عملاً هیچ نیازی به IO ذخیرهسازی ندارند. مقدار کمی وجود دارد، عمدتاً برای لاگگیری سیستم، اما این تقریباً تمام چیزی است که نیاز است. پارتیشنهای سیستمعامل تقریباً کاملاً ثابت هستند. اجزای مورد نیاز در حافظه بارگذاری میشوند، عمدتاً در زمان بوت، و دیگر دسترسی پیدا نمیشوند. حتی در مواردی که لاگگیری مورد نیاز است، بسیاری از اوقات این لاگها به یک سیستم لاگگیری مرکزی ارسال میشوند نه به ناحیه ذخیرهسازی سیستم، که آن نیاز را کاهش میدهد یا حتی حذف میکند.
با هایپروایزرها این اثر حتی بیشتر است. از آنجا که هایپروایزرها بسیار سبکتر و کمتر قوی از سیستمعاملهای سنتی هستند، بیشتر شبیه سیستمهای تعبیهشده رفتار میکنند و در بسیاری از جهات در واقع در بسیاری از موارد سیستمهای تعبیهشده هستند. هایپروایزرها در زمان بوت سیستم در حافظه بارگذاری میشوند و رسانهشان تقریباً هرگز در حین اجرای سیستم، به جز برای لاگگیری در برخی مواقع، مورد نیاز نیست. از آنجا که هایپروایزرها از نظر حجم فیزیکی کوچک هستند، حتی کل زمان مورد نیاز برای خواندن کامل یک هایپروایزر از ذخیرهسازی بسیار کوچک است، حتی روی رسانههای بسیار کند، زیرا حجم کل بسیار کوچک است.
به این دلایل، عملکرد ذخیرهسازی برای سیستمعاملها و بهویژه هایپروایزرها از کم تا هیچ اهمیت ندارد. تفاوت بین ذخیرهسازی سریع و کند واقعاً فقط بر زمان بوت سیستم تأثیر میگذارد که در آن تفاوت یک ثانیه یا سی ثانیه بهندرت توجه کسی را جلب میکند، اگر اصلاً جلب کند. چه کسی حتی چند ثانیه اضافی در طول راهاندازی سیستم را درک میکند و در بیشتر موارد، راهاندازیها رویدادهای نادری هستند که حداکثر یک بار در هفته در طول یک راهاندازی مجدد خودکار و روتین سیستم در طول یک پنجره نگهداری برنامهریزیشده یا بهندرت، گاهی اوقات فقط یک بار در چند سال، برای سیستمهایی که تنها در شرایط اضطراری آفلاین میشوند اتفاق میافتند. حتی کندترین سیستم ذخیرهسازی تصورپذیر برای این نقش بسیار سریعتر از حد لازم است.
حتی ذخیرهسازی کند بهطور کلی چند برابر سریعتر از آنچه برای فعالیتهای لاگگیری سیستم لازم است میباشد. در آن موارد نادری که لاگگیری بسیار شدید است، گزینههای زیادی برای مقابله با این مشکل داریم. واضحترین و رایجترین راهحل اینجا ارسال لاگها به یک آرایه دیسک غیر از آنی است که توسط سیستمعامل یا هایپروایزر استفاده میشود. این یک راهحل بسیار آسان است و در نهایت در مواردی که توجیه دارد بسیار عملی است. راهحل رایج و بسیار مفید دیگر این است که بهسادگی از نگهداری لاگها روی دستگاه محلی خودداری کنیم و آنها را به یک ابزار جمعآوری لاگ از راه دور مانند Splunk، Loggly یا ELK ارسال کنیم.
نگرانی اصلی دیگری که اغلب مردم در مورد سیستمعاملها و هایپروایزرهایشان دارند قابلیت اطمینان است. معمول است که تلاشهای بیشتری صرف محافظت از این جنبههای نسبتاً غیرمهم سیستم شود تا از دادههای اغلب غیرقابل جایگزینی. با این حال، سیستمعاملها و هایپروایزرها بهراحتی از صفر زمانی که لازم است با نصبهای تازه و پیکربندی مجدد دستی بازسازی میشوند. جزئیاتی که ممکن است از دست بروند معمولاً نسبتاً بیاهمیت هستند و میتوان آنها را دوباره ایجاد کرد.
البته این به این معنا نیست که این فایلسیستمهای سیستمی نباید پشتیبانگیری شوند، البته باید (در اغلب موارد). اما فقط در صورتی که پشتیبانها هم خراب شوند، از دست دادن پارتیشن یا فایلسیستم سیستمعامل بهندرت واقعاً فاجعه است، بلکه فقط یک ناراحتی است. در تقریباً تمام موارد بدون دسترسی به داده اصلی میتوان بازیابی کرد، به شرطی که فایلسیستم «داده» جداگانه باشد. و به دلیل ماهیت سیستمعاملها و هایپروایزرها، تغییر نادر است، بنابراین پشتیبانها میتوانند بهطور کلی کمتر مکرر باشند، احتمالاً فقط زمانی که بهروزرسانیها اعمال میشوند بهصورت دستی فعال شوند!
با بسیاری از سیستمهای مدرن در فضاهای DevOps و رایانش ابری، بسیار رایج شده است که فایلسیستمهای سیستمعامل و هایپروایزر را کاملاً یکبار مصرف ببینیم زیرا از طریق تصویر سیستم یا یک سیستم مدیریت پیکربندی به صورت از راه دور تعریف میشوند. در این موارد، که هر چه بیشتر رایج میشوند، نیازی به محافظت از داده یا پشتیبانگیری نیست زیرا کل سیستم برای بازسازی، تقریباً فوری، بدون هیچ تعامل خاصی طراحی شده است. سیستم کاملاً خودتکرارشونده است. این نیاز به محافظت از فایلسیستم سیستم را بیشتر کماهمیت میکند.
با در نظر گرفتن همه اینها، فقدان نیاز به عملکرد و فقدان نیاز به محافظت و قابلیت اطمینان که عمدتاً از طریق بازسازی ساده مدیریت میشود، آنچه داریم یک فایلسیستم سیستم با نیازهای بسیار متفاوت از آنچه معمولاً فرض میکنیم است. این به این معنا نیست که باید با ذخیرهسازیمان بیملاحظه باشیم، همچنان میخواهیم از خرابی ذخیرهسازی در حین اجرای سیستم جلوگیری کنیم و بازسازی غیرضروری اتلاف وقت و منابع است حتی اگر فاجعهآور نباشد. بنابراین ایجاد تعادل دقیق مهم است.
البته، به همین دلایل است که شامل کردن سیستمعامل یا هایپروایزر روی همان آرایه ذخیرهسازی با داده اکنون یک عمل رایج است — زیرا نیاز کمی یا هیچ نیازی به دسترسی ذخیرهسازی به فایلهای سیستمی همزمان با دسترسی به فایلهای داده وجود ندارد، بنابراین با دریافت زمانهای بوت سریع برای سیستمعامل و بدون تأثیر منفی بر زمانهای دسترسی داده پس از آنلاین شدن سیستم، همافزایی عالی میگیریم. این روش اصلی است که طراحان سیستم امروز برای نیاز به استفاده کارآمد از ذخیرهسازی بکار میبرند.
وقتی سیستمعامل یا هایپروایزر باید از آرایههای نگهدارنده داده جدا شوند که هنوز به دلایل بسیاری میتواند اتفاق بیفتد، بهطور کلی به دنبال دستیابی به قابلیت اطمینان معقول با هزینه کم هستیم. هنگام استفاده از ذخیرهسازی سنتی (دیسکهای محلی)، این به معنای استفاده از دیسکهای دوار کوچک، کند، کمهزینه برای ذخیرهسازی سیستمعامل، معمولاً در پیکربندی RAID 1 ساده است. یک مثال واقعی استفاده از دیسکهای SATA با سرعت ۵۴۰۰ دور در دقیقه «دوستدار محیط زیست» در کوچکترین اندازههای ممکن است. اینها انرژی کمی مصرف میکنند و خرید آنها بسیار ارزان است. از SSDها و دیسکهای SAS پرسرعت باید اجتناب شود زیرا برای محافظتی که غیرمرتبط است و عملکردی که کاملاً هدر میرود، هزینه اضافی میطلبند.
در ذخیرهسازی کمتر سنتی، استفاده از یک SAN ارزانقیمت با تراکم بالا برای تجمیع ذخیرهسازی با اولویت پایین بسیاری از سیستمها روی آرایههای مشترک کند و غیرتکرارشونده رایج است. این تنها در محیطهای بزرگتری مؤثر است که میتوانند طراحی معماری اضافی را توجیه کنند و میتوانند به اندازه کافی در فرایند تجمیع ذخیرهسازی به تراکم دست یابند تا صرفهجویی هزینه لازم را ایجاد کنند، اما در محیطهای بزرگتر این نسبتاً آسان است. دستگاههای بوت SAN میتوانند از آرایههای بسیار ارزانقیمت در بسیاری از سرورها برای صرفهجویی هزینه استفاده کنند. در فضای مجازی این میتواند به معنای یک دیتااستور با عملکرد پایین برای دیسکهای مجازی سیستمعامل و یک استخر دیگر با عملکرد بالا برای دیسکهای مجازی داده باشد. این همان اثر استراتژی بوت SAN را خواهد داشت اما در محیطی مدرنتر و بهراحتی میتواند از معماری SAN در زیرساخت برای رسیدن به آن استفاده کند.
در نهایت، و بهطور چشمگیرتر، یک قانون کلی با هایپروایزرها این است که آنها را روی کارتهای SD یا دستگاههای USB نصب کنیم به جای ذخیرهسازی سنتی، زیرا نیازهای عملکرد و قابلیت اطمینان آنها بسیار کمتر از سیستمعاملهای سنتی است. بهطور معمول اگر چنین دیسکی در حین اجرای سیستم خراب شود، سیستم در واقع بدون هیچ مشکلی به اجرا ادامه میدهد زیرا از دیسک هرگز پس از بوت اولیه سیستم استفاده نمیشود. تنها در طول راهاندازی مجدد مشکلی پیدا میشود و در آن زمان، یک دستگاه بوت پشتیبان مانند یک کارت SD یا USB دوم میتواند استفاده شود. این توصیه رسمی برای VMware vSphere است، اغلب توسط نمایندگان Microsoft برای HyperV توصیه میشود و از طریق فروشندگان OEM HyperV بهطور رسمی پشتیبانی میشود و اغلب، اما نه به آن گستردگی، برای سیستمهای Xen، XenServer و KVM توصیه میشود. استفاده از کارتهای SD یا دیسکهای USB برای ذخیرهسازی هایپروایزر بهطور مؤثر یک سرور مجازیسازی را به یک سیستم تعبیهشده تبدیل میکند. در حالی که این ممکن است برای مدیران سیستمی که به فکر کردن درباره دیسکهای سنتی به عنوان ضرورتی برای سرورها عادت دارند غیرطبیعی احساس شود، مهم است به یاد داشته باشیم که سیستمهای سازمانی، بسیار حیاتی مانند روترها و سوئیچها دههها دوام میآورند و دقیقاً همین استراتژی را به دقیقاً همین دلایل استفاده میکنند.
یک استراتژی رایج برای هایپروایزرها در این حالت تعبیهشده با کارتهای SD یا دیسکهای USB این است که دو چنین دستگاهی داشته باشیم، که ممکن است در واقع یک کارت SD و یک دیسک USB باشد، هر کدام با یک کپی از هایپروایزر. اگر یک دستگاه خراب شود، بوت شدن از دستگاه دوم تقریباً به اندازه یک سیستم RAID 1 سنتی مؤثر است. اما برخلاف اغلب تنظیمات RAID 1 سنتی، همچنین ابزار نسبتاً آسانی برای آزمایش بهروزرسانیهای سیستم داریم که فقط یک دستگاه بوت را در یک زمان بهروزرسانی میکنیم و فرآیند را قبل از بهروزرسانی دستگاه بوت دوم آزمایش میکنیم، که یک بازگشتی قابل اطمینان و بهخوبی آزمودهشده در صورتی که بهروزرسانی نسخه دچار مشکل شود برای ما باقی میگذارد. این فرآیند در واقع روی سیستمهای RISC UNIX بزرگ رایج بود که در آن دستگاههای بوت اغلب مجموعههای RAID 1 نرمافزاری محلی بودند که از یک عمل مشابه پشتیبانی میکردند، بهویژه رایج در حلقههای AIX و Solaris.
همچنین باید توجه داشت که در حالی که این رویکرد بهترین روش برای اغلب سناریوهای هایپروایزر است، در واقع هیچ دلیلی وجود ندارد که نتوان آن را به فایلسیستمهای سیستمعامل کامل هم اعمال کرد، به جز اینکه اغلب کار بیشتری است. برخی سیستمعاملها، بهویژه Linux و BSD در نصب به شیوه تعبیهشده بسیار ماهر هستند و میتوانند بهراحتی با کمی برنامهریزی برای نصب روی کارت SD یا دیسک USB تطبیق داده شوند. این رویکرد به هیچ وجه رایج نیست، اما هیچ دلیل فنی وجود ندارد که در شرایط مناسب، رویکرد عالی نباشد، به جز اینکه تقریباً هرگز نباید سیستمعاملی روی سختافزار فیزیکی نصب شود نه روی هایپروایزر. در آن موارد که نصبهای فیزیکی ضروری هستند، این رویکرد بسیار معتبر است.
هنگام طراحی و برنامهریزی برای سیستمهای ذخیرهسازی، به خاطر داشته باشید که به الگوهای واقعی خواندن و نوشتن در هنگام اجرای سیستم توجه کنید. و به یاد داشته باشید که ذخیرهسازی از زمان توسعه بسیاری از رهنمودهای سنتی بهطور کاملاً چشمگیری تغییر کرده است و همه دانشی که برای توسعه آنها استفاده شده امروز یا به یک اندازه کاربرد ندارد. نهتنها به اینکه کدام زیرسیستمهای ذخیرهسازی تلاش میکنند از عملکرد ذخیرهسازی استفاده کنند فکر کنید، بلکه به اینکه چگونه با یکدیگر تعامل دارند (مثلاً آیا دو سیستم هرگز بهطور همزمان دسترسی ذخیرهسازی درخواست نمیکنند یا آیا بهطور منظم با هم تداخل دارند) و اینکه آیا عملکرد دسترسی آنها مهم است. عملکردهای کلی سیستمعامل میتوانند روی یک سرور پایگاه داده فوقالعاده کند باشند بدون هیچ تأثیر منفی، تنها چیزی که اهمیت دارد سرعت دسترسی به پایگاه داده است. حتی دسترسی به باینریهای برنامه اغلب غیرمرتبط است زیرا آنها هم، پس از بارگذاری در حافظه، در آنجا باقی میمانند و فقط سرعت حافظه بر عملکرد مداوم تأثیر میگذارد.
هیچیک از اینها به معنای پیشنهاد جداسازی زیرسیستمهای ذخیرهسازی سیستمعامل و داده از یکدیگر نیست، که اغلب توصیه نمیشود. در گذشته درباره اینکه تجمیع این زیرسیستمها اغلب بهترین مسیر عمل است نوشتهام و این همچنان درست است. اما موارد معقول بسیاری هم وجود دارند که در آنها جداسازی برخی نیازهای ذخیرهسازی از یکدیگر منطقی است، اغلب هنگام برخورد با سیستمهای مقیاس بزرگ که میتوانیم هزینه را با اختصاص ذخیرهسازی پرهزینه به نیازهای خاص و ذخیرهسازی کمهزینه به نیازهای دیگر کاهش دهیم، و در آن موارد است که میخواهم نشان دهم که سیستمعاملها و هایپروایزرها باید کماولویتترین از نظر عملکرد و قابلیت اطمینان در نظر گرفته شوند، به جز در بیشترین موارد افراطی.
آگهی
