مدل‌های میزبانی را از طریق مسئولیت‌های عملیاتی که تعیین می‌کنند و معماری‌ای که ممکن می‌سازند مقایسه کنید. مقیاس ابری، یک ماشین مجازی و سخت‌افزار اختصاصی جنبه‌های متفاوتی از یک سیستم را توصیف می‌کنند؛ هیچ‌کدام به‌تنهایی اثبات‌کننده حریم خصوصی، هزینه یا رفتار بازیابی نیست.
با کاری شروع کنید که نیاز دارید کسی مسئولیت آن را بپذیرد
یک تصمیم میزبانی هم منابع محاسباتی و هم کار عملیاتی تعیین می‌کند. یک پروژه به حسابی نیاز دارد که یک وب‌سایت متعارف را اجرا کند؛ پروژه‌ای دیگر به کنترل بسته‌های سیستم‌عامل و فرآیندهای پس‌زمینه نیاز دارد. پروژه سوم به یک پلتفرم پایگاه داده نیاز دارد که نگهداری آن تحت قرارداد خدمات مشخصی انجام شود. ابتدا این مسئولیت‌ها را همراه با افراد در دسترس برای نگهداری آن‌ها فهرست کنید.
میزبانی اشتراکی معمولاً یک محیط در سطح حساب ارائه می‌دهد. یک VPS یک سیستم‌عامل مهمان ارائه می‌دهد، در حالی که سخت‌افزار اختصاصی مرز ماشین را به یک سرور فیزیکی منتقل می‌کند. مدیریت‌شده پرسشی جداگانه است: برچسب یک محصول به شما نمی‌گوید چه کسی وصله‌ها را اعمال می‌کند، داده‌ها را بازیابی می‌کند یا یک رخداد را بررسی می‌کند. به‌جای برخورد با آن به‌عنوان یک ویژگی جهانی، محدوده مدیریت و رویه بازیابی را بخواهید.
درک کنید ابر چه چیزی به مقایسه اضافه می‌کند
NIST رایانش ابری را از طریق ویژگی‌هایی مانند دسترسی برحسب تقاضا، تجمیع منابع، کشش‌پذیری و سرویس اندازه‌گیری‌شده توصیف می‌کند. یک ماشین مجازی می‌تواند یکی از مؤلفه‌های یک پلتفرم ابری باشد، بنابراین VPS و ابر فناوری‌هایی ناسازگار نیستند. مقایسه مفید میان سرویس‌های مشخص ارائه‌شده است: یک ماشین مجازی ثابت، یک ناوگان کشسان یا برنامه‌ای ساخته‌شده حول سرویس‌های مدیریت‌شده.
Hyperscaler اصطلاحی صنعتی برای ارائه‌دهنده‌ای است که زیرساخت و پلتفرم‌های سرویس را در مقیاس بسیار بزرگ اداره می‌کند. این مقیاس می‌تواند طیف گسترده‌ای از ابزارهای استقرار و گزینه‌های جغرافیایی ارائه دهد؛ اما به شما نمی‌گوید آیا یک معماری خاص نیازهای شما را برآورده می‌کند. منطقه، وابستگی‌های سرویس، مدل هویت و قرارداد هر مؤلفه را ارزیابی کنید. هم ارائه‌دهنده کوچک‌تر و هم پلتفرم بزرگ نیازمند تصویری روشن از مقصد داده‌ها هستند.
| مدل عملیاتی | کنترل در دسترس پروژه | پرسش پیش از انتخاب |
|---|---|---|
| حساب میزبانی اشتراکی | تنظیمات سایت در محدوده حساب | آیا محیط اجرا با برنامه سازگار است؟ |
| ماشین مجازی | سیستم‌عامل مهمان و سرویس‌های نصب‌شده | چه کسی مهمان را نگهداری و بازیابی می‌کند؟ |
| ماشین اختصاصی | یک مرز سرور فیزیکی | آیا بار کاری این مرز را توجیه می‌کند؟ |
| سرویس ابری مدیریت‌شده | API سرویس و تنظیمات پشتیبانی‌شده | چه چیزی همچنان مسئولیت مشتری است؟ |
معماری‌ای انتخاب کنید که بتواند بازیابی شود
یک ماشین واحد می‌تواند نقطه شروع معقولی برای یک برنامه کوچک باشد، زمانی که الزامات بازیابی آن اجازه بازیابی یا یک پنجره نگهداری برنامه‌ریزی‌شده را بدهد. افزودن یک گره برنامه دوم تنها در صورتی طراحی را تغییر می‌دهد که مسیریابی ترافیک، نشست‌ها و داده‌های پایدار روی هر دو به‌درستی کار کنند. دو سرور که همان طرح بازیابی ناقص را اجرا می‌کنند، همچنان یک طرح بازیابی ناقص هستند.
ذخیره‌سازی توزیع‌شده این تمایز را نشان می‌دهد. نرم‌افزاری مانند Ceph کار ذخیره‌سازی را روی یک خوشه پخش می‌کند و رابط‌های شیء، بلوک و فایل ارائه می‌دهد. تکرار یا کدگذاری پاک‌کننده ممکن است به تحمل خرابی‌های خاص سخت‌افزاری کمک کند، اما خوشه به ظرفیت برای بازیابی و بازتوازن نیز نیاز دارد. یک نسخه زنده توزیع‌شده جایگزین پشتیبان مستقل نمی‌شود. تصمیم بگیرید نوشتن‌ها در هنگام پارتیشن شبکه چگونه رفتار می‌کنند و موارد شکست مرتبط با پیاده‌سازی انتخابی خود را آزمایش کنید.
بودجه عملیاتی کامل را مقایسه کنید
بودجه را به‌صورت یک بار کاری بنویسید: ترافیک عادی، بازه پرترافیک، داده ذخیره‌شده، مدت نگهداری پشتیبان و انتقال لازم برای بازیابی. نرم‌افزار پولی، APIهای خارجی، زمان مدیریت و هزینه انتقال دوباره داده را شامل شوید. یک رقم ماهانه شروع و یک برآورد مبتنی بر مصرف به پرسش‌های متفاوتی پاسخ می‌دهند. آن‌ها را در بازه زمانی یکسان مقایسه کنید و فرض‌ها را در کنار نتیجه نگه دارید.
برای یک پلتفرم ابری بزرگ، هر سرویس لازم برای ادامه کار برنامه را مشخص کنید. برای یک VPS، کاری را که سرویس‌های مدیریت‌شده در غیر این صورت جذب می‌کنند شامل شوید. هیچ‌یک از این دو رویکرد به‌طور خودکار ارزان‌تر نیست. با یک استقرار کوچک نماینده یا یک قیمت مستند شروع کنید، سپس صورتحساب واقعی را با مدل مقایسه کنید. برای ترافیک بازیابی و ظرفیت مهاجرت موقت جا رزرو کنید، نه اینکه فقط حالت پایدار را بودجه‌بندی کنید.
با حریم خصوصی مانند یک نقشه وابستگی رفتار کنید
منطقه ماشین یک ورودی در نقشه‌ای گسترده‌تر است. احراز هویت، پایش، ابزارهای پشتیبانی، پشتیبان‌ها و APIهای مدل ممکن است از طریق سرویس‌های جداگانه فعالیت کنند. ثبت کنید هر کدام چه چیزی دریافت می‌کنند، چه کسی می‌تواند به آن دسترسی داشته باشد و چه مدت نگهداری می‌شود. مدل مسئولیت مشترک AWS یک نمونه از ارائه‌دهنده‌ای است که به‌صراحت وظایف زیرساختی خود را از وظایف مشتری جدا می‌کند؛ محدوده با سرویس تغییر می‌کند.
هنگام مقایسه ارائه‌دهندگان از این تمایز استفاده کنید و تعهدات یک ارائه‌دهنده را به قرارداد دیگری وارد نکنید. پیکربندی SwissOctet یک مکان میزبانی و منابع فهرست‌شده را توصیف می‌کند. این پیکربندی مکان یکپارچه‌سازی‌هایی را که بعداً اضافه می‌کنید مشخص نمی‌کند. داده‌ای را که هر وابستگی دریافت می‌کند به حداقل برسانید، مدیریت را امن کنید و مقصدهای پشتیبان را پیش از اظهارنظر درباره مسیر داده برنامه خودتان تأیید کنید.
از مسیر مهاجرت به‌عنوان بخشی از تصمیم استفاده کنید
بررسی کنید چگونه می‌توانید داده‌های برنامه، پیکربندی و هویت‌ها را صادر کنید. یک برنامه متعارف روی ماشین مجازی ممکن است جابه‌جایی ساده‌ای داشته باشد، در حالی که یک پایگاه داده یا سیستم رویداد مخصوص سرویس ممکن است نیازمند سازگارسازی باشد. قابلیت حمل به دانش عملیاتی نیز بستگی دارد: پشتیبانی که هیچ‌کس نمی‌داند چگونه بازیابی کند، یک طرح خروج ضعیف است، حتی اگر قالب آن باز باشد.
برای یک فهرست کوتاه اولیه SwissOctet، Canvas را زمانی مقایسه کنید که یک محیط وب در سطح حساب مناسب است، Vector را برای کنترل سیستم‌عامل مهمان و محدوده‌های Metal را زمانی که مرز فیزیکی اهمیت دارد. گزینه‌های ذخیره‌سازی‌محور از یک پرسش ظرفیت متفاوت پشتیبانی می‌کنند و نباید به‌عنوان یک خوشه توزیع‌شده مدیریت‌شده توصیف شوند. معماری را به‌اندازه‌ای کوچک نگه دارید که قابل اداره باشد، و پیچیدگی پلتفرم را زمانی اضافه کنید که به یک نیاز آزمایش‌شده پاسخ دهد، نه به مقیاس آینده‌ای خیالی.
چک‌لیست عملی شما.
- مالکیت مدیریت و بازیابی را تعیین کنید.
- یک VM را از پلتفرم ابری گسترده‌تر متمایز کنید.
- وابستگی‌ها، انتقال و نگهداری را بودجه‌بندی کنید.
- پیش از افزودن گره‌ها، یک مرز شکست را آزمایش کنید.
- یک مسیر عملی صادرات داده و مهاجرت ثبت کنید.
جزئیاتی که اهمیت دارند.
آیا یک VPS می‌تواند بخشی از یک پلتفرم ابری باشد؟+
بله. یک ماشین مجازی می‌تواند یک سرویس ابری باشد. به‌جای فرض اینکه نام‌ها فناوری‌های انحصاری را توصیف می‌کنند، مدل واقعی منابع، مقیاس‌پذیری و مدیریت را مقایسه کنید.
آیا ذخیره‌سازی توزیع‌شده جایگزین پشتیبان‌ها می‌شود؟+
خیر. افزونگی زنده به خرابی‌های مؤلفه‌های منتخب می‌پردازد. یک پشتیبان مستقل و یک آزمایش بازیابی به خرابی‌های دیگر مانند حذف و داده‌های آسیب‌دیده برنامه می‌پردازند.
آیا ابر بزرگ همیشه انتخاب ضعیفی برای حریم خصوصی است؟+
خیر. سرویس‌های مشخص، جریان‌های داده و کنترل‌های قراردادی را ارزیابی کنید. اندازه ارائه‌دهنده به‌تنهایی مناسب بودن معماری را اثبات نمی‌کند.
به منبع بروید.
این منابع از مفاهیم فنی این راهنما پشتیبانی می‌کنند. پیش از تغییر یک سیستم تولیدی، مستندات جاری را دنبال کنید.
- NIST SP 800-145: تعریف رایانش ابری nvlpubs.nist.gov
- AWS: مدل مسئولیت مشترک aws.amazon.com
- Ceph: معماری ذخیره‌سازی docs.ceph.com
- Ceph: کدگذاری پاک‌کننده docs.ceph.com
راهنمایی تحریریه توسط SwissOctet. مثال‌ها نمایشی هستند. مشخصات خدمات، گزینه‌های موجود و شرایط قراردادی باید جداگانه تأیید شوند.