مجازی‌سازی و دیتاسنترهای متمرکز، شیوه‌ی نگرش سازمان‌ها را به هزینه‌های سرمایه‌گذاری (CapEx) و هزینه‌های عملیاتی OpEx تغییر داده و دوره‌ی روزهایی که افزودن برنامه‌های کاربردی یا ظرفیت جدید صرفا از طریق خرید بیشتر محصول سخت افزاری یا نرم افزاری انجام می‌شد، به پایان رسیده است. امروزه CIOها و طراحان به دنبال به حداکثر رساندن بازدهی سرمایه‌گذاری در سخت‌افزار و نرم‌افزار از طریق فناوری‌های مجازی‌سازی هستند که به آنها اجازه می‌دهد از هر ذره از توان محاسباتی دیتاسنترهای موجودشان استفاده کنند.
این یک دلیل کاملا مشخص در دنیای Application Serverها می‌باشد، اما مزایای بالقوه برای دیگر تجهیزات، فایروال‌ها، Routerها و Application Delivery Controllerها یا به اختصار ADCها نیز به همراه دارد که غیرقابل انکار می‌باشد. در نتیجه اکثر Vendorها استراتژی‌هایی را حول Applianceهای مجازی یا Multi-Tenancy در شکل‌های مختلف پیشنهاد می‌کنند تا همان نوع از انعطاف‌پذیری را که مجازی‌سازی سیستم عامل (OS) در دنیای سرورها عرضه می‌کند، برای راهکارهایشان ارائه نمایند. با توجه به آنکه هردو Applianceهای مجازی و Multi-Tenancy انعطاف‌پذیری پیاده‌سازی سازمان‌ها و قابلیت‌شان را برای گرفتن حداکثر ROI هم از CapEx و هم از OpEx در کوتاه مدت بهبود می‌بخشند؛ اما این استراتژی‌ها موفق نشده‌اند راهکارهای دارای عملکرد بالا و قابلیت اطمینان بالا را مشابه سیستم‌های هدفمند سنتی ارائه نمایند.
اما این موضوع به تازگی تغییر کرده است. فناوری (F5 Virtual Clustered Multiprocessing (vCMP، همراه با فناوری Clustered Multiprocessing یا به اختصار CMP، نرم‌افزار ارائه‌ی برنامه‌ی کاربردی، سخت‌افزار هدفمند و راهکارهای Virtual Edition یا به اختصار VE، به سازمان‌ها یک استراتژی مجازی‌سازی End-to-end و کامل را برای ارائه‌ی برنامه‌ی کاربردی داده است.
زمانی که سازمان‌ها شروع به تجمیع دیتاسنترهای خود کردند، دریافتند که برای موفقیت باید تمام موارد اضافی را حذف کنند؛ صرفا انتقال سیستم‌های Remote به یک مرکز داده، به سرعت تمام فضا، توان و Cooling در دسترس را مصرف می‌کرد. به علاوه، اکثر آن سیستم‌ها نسبت به آنچه که توسط سخت‌افزاری که روی آن پیاده‌سازی شده بودند، ارائه شده بود، از ظرفیت سخت‌افزاری کمتری استفاده می‌کردند. بسیاری از سازمان‌ها طبق روند معمول، سخت‌افزار سرورشان را Over-Provision (بالاتر از حد مصرف‌شان) حساب می‌کردند تا با تقاضای غیرقابل پیشبینی یا رشد در آینده تطبیق پیدا کند. در ساختارهای جداگانه این کار کاملا معقول است؛ با این‌حال، نتیجه‌ی صدها بار همسان‌سازی این استراتژی بر روی صدها برنامه‌ی کاربردی، مقادیر کلانی از منابع استفاده نشده بود که صرفا در مرکز داده هدر می‌رفتند. Applianceهای دیتاسنتر نیز بنا به همین دلایل، به Over-Provision شدن سوق پیدا می کردند. احیای این منابع راکد جهت به حداقل رساندن میزان فضای Rack، توان و Cooling مورد نیاز، به عنوان یک هدف بسیار مهم در تجمیع دیتاسنتر مطرح شد.
بااینحال، همچنان مهم است که بار غیرقابل پیشبینی و رشد در آینده مد نظر قرار گیرد. بر روی کاغذ، به نظر می‌رسد راهکارهای مجازی‌سازی تجاری مناسب باشند، اما هرکدام ضعف‌هایی را نیز دارند. این راهکارها به دو شکل کلی ظاهر می‌شوند: Applianceهای مجازی و Multi-Tenancy.
بررسی ضعف‌های Multi-Tenancy
بسیاری از فروشندگان Applianceها از Multi-tenancy جهت جداسازی مدیریت خاص سرویس‌ها برای گروه‌های متمایز استفاده می‌کنند. یک سازمان از طریق جداسازی پنل مدیریتی می‌تواند دستگاهی را برای سرویس‌دهی به چندین مشتری یا نهاد‌های تجاری بدون این که مشتریان، متوجه شوند دیگران هم از همان راهکار فیزیکی استفاده می‌کنند، پیکربندی کند. در حالی که این امر، ظاهرا جدایی بین Tenantها را دارد، حقیقت این است که تمام آنها منابع سخت‌افزار یکسانی را سهیم می‌شوند. بنابراین اگر هریک از مشتری‌ها بخش خودش از سیستم را Misconfigure کند یا موجب استفاده‌ی بیش از اندازه از آن منابع شود، این امر می‌تواند تاثیر منفی بر دیگر کاربرها بگذارد. راهکارهای Multi-Tenant کنترل‌های پیشرفته‌ای را برای کاهش این احتمال ارائه می‌نمایند (مانند پردازنده، حافظه و محدودیت‌های پهنای باند)؛ بااینحال، همچنان محتمل بودن این امر، این راهکارها را در بسیاری موارد نامساعد می‌کند.
Multi-Tenancy محدودیت‌های دیگری دارد: برای مثال از کار افتادن سخت‌افزار بر چند مشتری تاثیر می‌گذارد؛ مشتری‌ها باید از نسخه‌های یکسان نرم‌افزار استفاده کنند، که انعطاف‌پذیری را محدود می‌کند؛ در حالی که مشتری‌ها به تنهایی بخش خاص خودشان را، از پیکربندی سیستم می‌بینند. پیکربندی کلی Appliance شامل تمام پیکربندی‌ها می‌شود که آن را برای مدیریت پیچیده و دشوار می‌سازد. نتیجه این است که در حالی که Multi-Tenancy به بسیاری از اهداف متمرکزسازی دست می‌یابد و می‌تواند CapEx را کاهش دهد، در طولانی مدت باعث افزایش OpEx می‌شود.
Applianceهای مجازی
Applianceهای مجازی نیز برای برطرف کردن نیازمندی‌های متمرکزسازی دیتاسنتر به کار می‌روند. یک Appliance مجازی، نرم‌افزاری را که پیش از این روی سخت‌افزار اختصاصی خود اجرا می‌شد، می‌گیرد و آن را به یک ماشین مجازی، که معمولا روی یک Hypervisor چندمنظوره همانند سایر ماشین‌های مجازی اجرا می‌گردد، تبدیل می‌کند و در صورت رخ دادن خطا یا نقص در منبع، منتقل گردند. این موضوع چند مزیت مهم دارد که توسط Multi-Tenancy ارائه نمی‌شد. ابتدا، هر Instance مجازی از هر Instance مجازی دیگر بر روی همان Host کاملا مستقل است، چه یک Appliance مجازی دیگر باشد، چه یک Instance برنامه‌ی کاربردی. در حالی که Appliance مجازی همچنان سخت‌افزار یکسانی را با دیگر Applianceهای مجازی شریک می‌شود، تفکیک بسیار متفاوت‌تر و کنترل‌شده‌تر از Multi-Tenancy است. در ثانی، اگر سخت‌افزار اصلی شکست بخورد یا یک Instance دیگر موجب به‌کارگیری بیش از حد منبع شود، Appliance مجازی می‌تواند نسبتا به راحتی و با کمی قطعی به Host دیگری منتقل گردد. این به برطرف کردن مشکل نواقص سخت‌افزار موثر بر چند مشتری و محدودیت‌های منابع که Multi-Tenancy قادر به رفع آنها نبود، کمک می‌کند.
متاسفانه وقتی صحبت از Applianceهای مجازی به میان می‌آیدکه میزان قابل توجهی از فرایندهای سنگین را انجام می‌دهند، بسیاری از سازمان‌ها متوجه شده‌اند که نمی‌توانند همان سطح از سرویس را نسبت به همتای فیزیکی‌شان ارائه نمایند، مخصوصا در محیط‌های متمرکزی که در آنها ترافیک افزایش یافته و از طرفی با تلاش بیشتر برای متمرکزسازی همراه است. سخت‌افزار اختصاصی‌ای که بسیاری از این Applianceها در ابتدا روی آن پیاده‌سازی شدند، شدیدا تخصصی شده و برای ارتقای عملکرد سیستم‌های چندمنظوره توانایی‌اش را داشتند طراحی گشته بود. به عنوان مثال، زمانی که Applianceها می‌بایست ترافیک شبکه‌ی Real-Time را پردازش می‌کردند، نرم‌افزار برای سخت‌افزار رابط شبکه‌ی خاصی تنظیم شده بود؛ اما این نرم‌افزار در یک پیاده‌سازی مجازی‌سازی شده تنها می‌تواند با رابط مجازی‌سازی شده تنظیم گردد، زیرا رابط فیزیکی هرگز مشخص نیست. به علاوه، پردازش داده‌های Real-time که توسط SSL/TLS کدگذاری شده‌اند به سخت‌افزار اختصاصی نیاز دارد تا از افزودن تاخیر (Latency) به شبکه اجتناب کند، به خصوص زمانی که کلیدهای SSL از 1024-bit به 2048-bit (که به 5 تا 7 برابر توان پردازش بیشتر نیاز دارد) تغییر کند. در حالی که قطعا می‌توان سخت‌افزار پردازش SSL را بر سرورهای متمرکز پیاده‌سازی کرد، باید روی هر ماشینی که Appliance مجازی ممکن است به آن منتقل شود، پیاده‌سازی گردد، که استفاده از منابع را در CapEx کاهش می‌دهد.
حتی بدون این مسائل و نگرانی‌ها، اجرای Applianceهای مجازی روی سخت‌افزار و یا Hypervisor یکسان به عنوان Instanceهای برنامه‌ی کاربردی مجازی‌سازی شده از آنجایی که نیازشان برای پردازنده، رابط شبکه و حافظه، اغلب برنامه‌های کاربردی دیگر را در مضیقه قرار می‌دهد، می‌تواند خطرناک باشد. این امر اغلب منجر به پیاده‌سازی شدن Applianceهای مجازی به عنوان تنها ماشین مجازی روی یک قطعه‌ی فیزیکی و مجزای سخت‌افزار، بسیار شبیه نسخه‌های مجازی‌سازی نشده‌ی سنتی اما به اضافه‌ی سربار یک Hypervisor، می‌شود.
در حالی که هم Multi-Tenancy و هم Applianceهای مجازی، ارزش بیشتری را نسبت Applianceهای یک‌بارمصرف سنتی ارائه می‌کنند، هر دو اشکالاتی دارند که مزیت کلی‌شان را محدود می‌کند. Multi-Tenancy کمبود جداسازی کامل، تحمل خطا و سهولت انتقال دارد و Applianceهای مجازی کمبود عملکرد سخت‌افزار هدفمند و اختصاصی را دارند. راهکاری ایده‌آل باید بتواند تمام این ویژگی‌ها را ارائه دهد.
