فقط به این دلیل که میتوانید...
این مفهوم را دائماً در بحثهای مربوط به مجازیسازی میبینم. این یک مفهوم کلیتر و عمومیتر است، اما مجازیسازی «فناوری داغ و جدید» است که بسیاری از سازمانهای فناوری اطلاعات با آن روبرو هستند و به نظر میرسد این فضایی است که در حال حاضر مشکلات «فقط چون میتوانی، نباید» بیشتر از همه خود را نشان میدهند. مانند همه چیز در فناوری اطلاعات، بسیار مهم است که تمام تصمیمات فنی در یک زمینه کسبوکاری قرار گیرند تا بفهمیم چرا آنچه را که انتخاب میکنیم انجام میدهیم و کورکورانه تلاش نکنیم تصمیمات خود را بر اساس روشهای استقرار رایج یا — بدتر از آن — اسطورهها بگیریم.
مجازیسازی به خودی خود، باید اشاره کنم، معتقدم باید امروز یک تصمیم پیشفرض برای کسانی باشد که در فضای محاسبات x64 کار میکنند و سیستمها باید بدون مجازیسازی استقرار یابند تنها زمانی که ضرورت واضح و آشکاری وجود داشته باشد مانند نیازهای سختافزاری خاص، برنامههای حساس به تأخیر و غیره. در غیاب هر نیاز خاصی، مجازیسازی از بسیاری از فروشندگان رایگان است و مزایای زیادی هم امروز و هم برای آیندهنگری محیط ارائه میدهد.
با این حال، آنچه امروز اغلب میبینم این است که شرکتها مجازیسازی را نه به عنوان یک بهترین روش، بلکه به عنوان راهحل همه مشکلات فناوری اطلاعات مشاهده شده استقرار میدهند. این قطعاً چنین نیست. مجازیسازی ابزار بسیار مهمی است که باید در جعبه ابزار فناوری اطلاعات داشت و اغلب به آن رجوع خواهیم کرد، اما هر مشکلی را حل نمیکند و باید مانند هر ابزار دیگری که داریم رفتار شود و تنها در صورت مناسب بودن استفاده شود.
چند چیز را میبینم که وقتی مجازیسازی به عنوان موضوع مطرح میشود تکرار میشوند. بسیاری از شرکتها امروز به سمت مجازیسازی حرکت میکنند نه به این دلیل که یک نیاز کسبوکاری را شناسایی کردهاند، بلکه چون موضوع پرطرفدار فعلی است و مردم احساس میکنند اگر مجازیسازی را پیادهسازی نکنند، به نوعی عقب میمانند یا از برخی عملکردهای اسطورهای محروم میشوند. این عموماً خوب است زیرا پذیرش مجازیسازی را افزایش میدهد، اما بد است چون فرآیندهای تصمیمگیری خوب فناوری اطلاعات و کسبوکار دور زده میشوند. آنچه اتفاق میافتد اغلب این است که در موج تبلیغات مجازیسازی، بخشهای فناوری اطلاعات احساس میکنند نه تنها باید خود مجازیسازی را پیادهسازی کنند بلکه باید این کار را به روشهایی انجام دهند که ممکن است برای کسبوکارشان مناسب نباشد.
چهار چیز وجود دارد که اغلب با مجازیسازی گره میخورند و اغلب به عنوان الزامات مجازیسازی پذیرفته میشوند، خواه در یک محیط کسبوکار خاص منطقی باشند یا نه. این موارد عبارتند از: تجمیع سرور، سرورهای بلید، ذخیرهسازی SAN و دسترسی بالا یا تبدیل فعال.
تجمیع آنقدر به عنوان مزیت مجازیسازی تبلیغ میشود که فکر میکنم اکثر بخشهای فناوری اطلاعات فراموش میکنند دلایل مهم دیگری برای پیادهسازی آن وجود دارد. واضح است که تجمیع مزیت بزرگی برای تقریباً تمام استقرارها است (البته مزایا میتواند متفاوت باشد) و تقریباً همیشه میتوان آن را صرفاً از طریق استفاده بهتر از منابع موجود به دست آورد. شرکتی که بیش از یک سرور فیزیکی دارد و نمیتواند از طریق تجمیع محدود، برخی هزینهها را کاهش دهد، بسیار نادر است و دیدن این که ردپای دیتاسنتر در سازمانهای بزرگتر کاهش چشمگیری پیدا میکند، غیرمعمول نیست.
اما در موارد شدید، رها کردن پروژههای مجازیسازی فقط به این دلیل که تجمیع امکانپذیر نیست ضروری نیست. این موارد برای شرکتهایی وجود دارند که سیستمهای با استفاده بالا و بودجه کمی برای سرمایهگذاری پیشگیرانه در تجمیع دارند. اما این شرکتها همچنان میتوانند سیستمها را «در جای خود» به صورت یک به یک مجازیسازی کنند تا از مزایای دیگر مجازیسازی امروز بهرهمند شوند و به دنبال تجمیع باشند وقتی سختافزار فردا نیاز به تعویض داشت یا وقتی سرورهای بزرگتر و قدرتمندتر در آینده مقرونبهصرفهتر میشوند. مهم است که مجازیسازی را فقط به این دلیل که مشهورترین مزیت آن ممکن است در حال حاضر در محیط شما اعمال نشود رد نکنید.
سرورهای بلید اغلب به عنوان بهترین انتخاب برای محیطهای مجازیسازی دیده میشوند. بلیدها ممکن است در یک محیط مجازیسازی استاندارد بهتر از حجمهای کاری محاسباتی سنتیتر عمل کنند، اما این هم بسیار قابل مجادله است و هم لزوماً دادههای قابل اعمال نیستند. خوب بودن یک سناریو برای خود بلیدها، آن را برای یک کسبوکار خوب نمیکند. فقط به این دلیل که بلیدها در این حالت بهتر از حالت عادی عمل میکنند به این معنی نیست که بهتر از سرورهای سنتی عمل میکنند — فقط اینکه بهطور بالقوه شکاف را کاهش دادهاند.
بلیدها باید با همان معیارهای سختگیرانه هنگام مجازیسازی ارزیابی شوند و اغلب همچنان در ارائه ارزش تجاری بلندمدت لازم برای انتخاب آنها بر جایگزینهای انعطافپذیرتر شکست میخورند. بلیدها همچنان بسیار دور از ضرورت برای مجازیسازی هستند و اغلب، به نظر من، انتخاب بسیار ضعیفی هستند.
یکی از رایجترین سوءتفاهمها این است که با حرکت به سمت مجازیسازی، باید به ذخیرهسازی مشترک مانند SAN نیز حرکت کرد. این طرز تفکر واکنش آشکار به تمایل به دستیابی به سایر مزایای مجازیسازی است که اگر SAN را نیاز ندارند، از آن بهره زیادی میبرند. توانایی توازن بار یا تبدیل اضطراری بین سیستمها به شدت با داشتن یک بکاند ذخیرهسازی مشترک تسهیل میشود. اسطورهای است که این یک الزام سخت باشد، اما ذخیرهسازی محلی تکرارشده پیچیدگیها و محدودیتهای خاص خود را دارد.
اما ذخیرهسازی مشترک به هیچ وجه ضرورتی برای خود مجازیسازی نیست و مانند هر چیزی باید به تنهایی ارزیابی شود. اگر مجازیسازی برای محیط شما منطقی است اما نیازی به ویژگیهایی که SAN را لازم دارند ندارید، بدون ذخیرهسازی مشترک مجازیسازی کنید. موارد زیادی وجود دارد که مجازیسازی با پشتیبانی ذخیرهسازی محلی یک سناریوی ایدهآل استقرار است. نیازی به رد کردن این رویکرد بدون اینکه ابتدا آن را جدی در نظر بگیرید وجود ندارد.
آخرین ویژگی ضروری فرضی مجازیسازی، دسترسی بالا در سطح سیستم یا تبدیل اضطراری فوری برای سیستمعامل شما است. بدون تردید، دسترسی بالا در لایه سیستم مزیت فوقالعادهای است که مجازیسازی به ما میدهد. با این حال، کمتر شرکتی پیش از پیادهسازی مجازیسازی به دسترسی بالا در این سطح نیاز داشت و قیمت زیرساخت و نرمافزار لازم برای انجام آن با مجازیسازی اغلب آنقدر بالا است که توجیه اقتصادی ندارد.
سیستمهای دسترسی بالا پیچیده و اغلب بیش از حد لازم هستند. سیستم کسبوکاری که نیاز به تبدیل اضطراری شفاف حتی برای حیاتیترین سیستمها داشته باشد بسیار نادر است و آن شرکتهایی که این الزام را دارند تقریباً مطمئناً قبلاً فرآیندهای تبدیل اضطراری داشتند. میبینم که شرکتها هنگام بررسی مجازیسازی به سمت دسترسی بالا میروند صرفاً به این دلیل که یک فروشنده فرصتی دید تا بهطور چشمگیری الزامات اصلی را بیش از حد بفروشد. هزینه دسترسی بالا به ندرت با از دست دادن درآمد احتمالی ناشی از کاهش مرتبط در زمان خرابی توجیه میشود. با مجازیسازی بدون دسترسی بالا، زمان خرابی برای یک دستگاه سختافزاری خراب در صورت خوب بودن پشتیبانگیری، ممکن است به دقیقهها اندازهگیری شود. این به این معناست که دسترسی بالا باید هزینه خود را در حذف احتمالی تنها چند دقیقه خرابی برنامهریزینشده در سال توجیه کند منهای هر خطر اضافی که پیچیدگی سیستم اضافه شده ایجاد میکند. حتی در بزرگترین سازمانها این به ندرت در هیچ مقیاس بزرگی توجیه دارد و در یک شرکت نسبتاً متوسط اصلاً غیرمعمول است. اما امروز بسیاری از کسبوکارهای کوچک سیستمهای دسترسی بالا را با هزینه زیاد روی سیستمهایی پیادهسازی میکنند که میتوانستند بهراحتی چند روز خرابی را با حداقل خسارت مالی تحمل کنند، صرفاً به این دلیل که ادبیات بازاریابی این مفهوم را تبلیغ کرده است.
مانند هر چیزی، مجازیسازی و تمام امکاناتی که به میز میآورد باید به صورت جداگانه در زمینه سازمانی که آنها را در نظر میگیرد ارزیابی شوند. اگر ویژگی فردی برای کسبوکار شما منطقی نیست، فرض نکنید که باید آن ویژگی را خریداری یا پیادهسازی کنید. بسیاری از سازمانها مجازیسازی میکنند اما تنها از چند — اگر نه هیچکدام — از این ویژگیهای «فرضی» استفاده میکنند. مجازیسازی را به عنوان یک جعبه سیاه نگاه نکنید، به بخشها نگاه کنید و آنها را همانطور که هر پروژه فناوری دیگری را در نظر میگیرید بسنجید.
آنچه اغلب اتفاق میافتد یک اثر گلوله برفی است که در آن یک ویژگی — احتمالاً دسترسی بالا — بدون انجام ارزیابی کسبوکاری مناسب، ضروری فرض میشود. سپس یک سیستم ذخیرهسازی مشترک، که اغلب برای دسترسی بالا ضروری فرض میشود، به عنوان هزینه فرضی دیگری اضافه میشود. حتی اگر ویژگیهای دسترسی بالا خریداری نشوند، تصمیم برای استفاده از SAN ممکن است قبلاً گرفته شده باشد و بعد از ایجاد تغییرات در طرح، مجدداً مورد بررسی قرار نگیرد. در تجربه من بسیار رایج است که در پروژههایی از این دست بیش از پنجاه درصد کل هزینه پروژه صرف محصولاتی شده باشد که خریدار حتی نمیتواند دلیل خرید آنها را توضیح دهد.
این مفهوم به مجازیسازی محدود نمیشود. آن را به همه کارهایی که انجام میدهید گسترش دهید. فناوری اطلاعات را در منظر کسبوکار نگه دارید و فرض نکنید که استفاده از یک فناوری بهطور خودکار به این معناست که باید فناوریهای دیگری را که بهطور رایج با آن مرتبط هستند نیز اتخاذ کنید.
آگهی
