آیا برای استفاده از زیروکلاینت به یک شبکه بسیار پرسرعت نیاز داریم؟ این یکی از اولین سوالاتی است که هنگام راهاندازی زیرساخت VDI و دسکتاپ مجازی مطرح میشود. تصور رایج این است که چون زیروکلاینت بیشتر پردازشهای خود را روی سرور انجام میدهد، بنابراین حجم زیادی از اطلاعات باید دائما در شبکه جابهجا شود. اما واقعیت کمی متفاوت است. پهنای باند زیروکلاینت یک عدد ثابت نیست. نوع فعالیت کاربران، پروتکل ارتباطی، تعداد مانیتورها، رزولوشن تصویر، محتوای ویدئویی، کیفیت شبکه و حتی نرخ تغییر تصاویر روی صفحه میتوانند میزان مصرف شبکه را تغییر دهند.
ممکن است کاربری که فقط با Word و نرمافزار حسابداری کار میکند چند صد کیلوبیت بر ثانیه مصرف داشته باشد، در حالی که کاربری دیگر هنگام مشاهده ویدئو، طراحی گرافیکی یا استفاده از چند مانیتور به چندین مگابیت بر ثانیه پهنای باند نیاز پیدا کند. بنابراین سؤال درست این نیست که «زیروکلاینت چقدر اینترنت مصرف میکند؟» بلکه باید پرسید: برای نوع کاربری سازمان ما چه مقدار پهنای باند لازم است؟
پهنای باند در سادهترین تعریف، ظرفیت انتقال اطلاعات در یک شبکه طی مدت مشخص است و معمولا با Kbps، Mbps یا Gbps اندازهگیری میشود. در یک رایانه سنتی، پردازش برنامهها عمدتا روی همان دستگاه انجام میشود. اما در معماری زیروکلاینت، بخش اصلی پردازش روی سرور، ماشین مجازی یا دیتاسنتر انجام خواهد شد و دستگاه کاربر نقش یک Endpoint را ایفا میکند.
ورودیهایی مانند حرکت موس و فشردن کلیدهای صفحهکلید از زیروکلاینت به سمت سرور ارسال میشوند. سرور نیز نتیجه پردازش و تغییرات تصویر را برای دستگاه کاربر میفرستد. در نتیجه، پهنای باند زیروکلاینت عمدتا تحت تاثیر حجم اطلاعات تصویری، صوتی و تجهیزات جانبی منتقلشده در یک Session قرار دارد.
نکته مهم اینجاست که پروتکلهای دسکتاپ از راه دور معمولا تصویر خام نمایشگر را دائما منتقل نمیکنند. آنها از روشهایی مانند: Compression، Caching و ارسال بخشهای تغییرکرده تصویر استفاده میکنند تا ترافیک شبکه کاهش پیدا کند. برای مثال، مایکروسافت توضیح میدهد که RDP فقط بخشهای تغییرکرده صفحه را انتقال میدهد و در زمانهایی که تصویر تقریبا ثابت است، مصرف شبکه بسیار پایین خواهد بود.
چرا ممکن است یک ماشین مجازی VMware با وجود داشتن CPU و RAM کافی، همچنان کند باشد؟ پاسخ معمولا فقط در منابع تخصیصیافته نیست؛ تأخیر Storage، رقابت ماشینها بر سر منابع، تنظیمات Hypervisor و وضعیت شبکه نیز میتوانند عملکرد را محدود کنند. مقاله با رویکرد آموزشی و فنی نوشته میشود تا هم برای کاربران عادی قابلفهم باشد و هم برای کارشناسان زیرساخت، راهنمای اولیهای برای عیبیابی فراهم کند. در این مقاله به توضیحات در رابطه با عملکرد ماشین های مجازی VMware میپردازیم.
کند شدن یک ماشین مجازی همیشه به معنای کمبود منابع سختافزاری نیست. گاهی سرور قدرتمندی در اختیار دارید، حافظه RAM کافی است و پردازنده نیز به حداکثر ظرفیت خود نرسیده؛ اما کاربران همچنان با تأخیر در اجرای نرمافزارها، کندی ورود به سیستم یا پاسخگویی نامناسب سرویسها مواجه میشوند. علت این وضعیت میتواند در لایهای پنهان از زیرساخت مجازیسازی باشد؛ از رقابت ماشینهای مجازی برای استفاده از CPU گرفته تا تأخیر دیسک، فشار حافظه و اختلال در شبکه.
درک صحیح عملکرد ماشین های مجازی VMware به مدیران فناوری اطلاعات کمک میکند بهجای افزایش بیهدف منابع، گلوگاه واقعی را شناسایی و برطرف کنند. در این مقاله، عوامل مؤثر بر کارایی ماشینهای مجازی، روشهای عیبیابی و راهکارهای بهینهسازی در محیط VMware vSphere را بررسی میکنیم.
ماشین مجازی (Virtual Machine) محیطی نرمافزاری است که منابعی مانند: پردازنده، حافظه، دیسک و کارت شبکه را به سیستمعامل مهمان ارائه میدهد. در زیرساختهای مبتنی بر VMware vSphere، این منابع از طریق Hypervisor و سختافزار میزبان مدیریت میشوند. عملکرد ماشین مجازی حاصل تعامل چندین مؤلفه است و بررسی یک شاخص بهتنهایی برای ارزیابی وضعیت آن کافی نیست.
فرض کنید کاربر فقط به Excel، AutoCAD، نرمافزار حسابداری یا یک برنامه سازمانی خاص نیاز دارد؛ اما برای اجرای آن مجبور نباشد یک دسکتاپ مجازی کامل دریافت کند. در این شرایط، چرا باید برای هر کاربر یک ماشین مجازی جداگانه ایجاد کنیم؟ اینجاست که App Sharing در Citrix و Horizon اهمیت پیدا میکند. در این معماری، برنامه در زیرساخت مرکزی اجرا میشود و کاربر فقط همان Application را روی سیستم خود مشاهده و استفاده میکند؛ بدون اینکه الزاماً یک Desktop کامل در اختیار داشته باشد. این روش علاوه بر سادهتر کردن مدیریت نرمافزارها، میتواند در طراحی صحیح، مصرف منابع زیرساخت را نیز بهینه کند.
App Sharing یا Application Sharing به روشی گفته میشود که در آن یک نرمافزار روی سرور یا ماشین مجازی اجرا شده و رابط کاربری آن از طریق یک ارتباط ریموت در اختیار کاربر قرار میگیرد. در این مدل، کاربر معمولا یک Published Application دریافت میکند. برای مثال، فرض کنید یک سازمان ۵۰۰ کاربر دارد اما تنها ۱۵۰ نفر از آنها به یک نرمافزار حسابداری خاص نیاز دارند. به جای اینکه برای هر کاربر یک Desktop کامل ایجاد شود، میتوان Application موردنظر را روی زیرساخت مرکزی قرار داد و فقط برای کاربران مجاز Publish کرد.
Published Application به برنامهای گفته میشود که در زیرساخت مرکزی اجرا شده و از طریق پلتفرمهایی مانند: Citrix یا Horizon در اختیار کاربر قرار میگیرد.کاربر ممکن است تصور کند نرمافزار مستقیما روی کامپیوترش اجرا میشود، اما پردازش اصلی در سرور یا ماشین مجازی انجام میشود. به عنوان نمونه:
کاربر → Citrix Workspace → زیرساخت Citrix → VDA → Application
در Horizon نیز ساختار مشابهی وجود دارد، اما Published Application معمولا در کنار فناوریهایی مانند RDSH مورد استفاده قرار میگیرد.
یک اختلال چند دقیقهای در دیتاسنتر ممکن است فقط یک خطای فنی به نظر برسد؛ اما برای یک سازمان، همین چند دقیقه میتواند به توقف سرویسها، از دسترس خارج شدن نرمافزارهای سازمانی، اختلال ارتباطات و حتی از دست رفتن بخشی از اطلاعات منجر شود. دیتاسنتر فقط مجموعهای از رکها و سرورها نیست. شبکه، تجهیزات ذخیرهسازی، سیستمهای مجازیسازی، فایروال، تجهیزات امنیتی، سیستمهای مانیتورینگ، بکاپ و بسیاری از سرویسهای نرمافزاری باید به شکل هماهنگ فعالیت کنند. به همین دلیل، پشتیبانی زیرساخت دیتاسنتر صرفا به معنای تعمیر یک سرور خراب نیست؛ بلکه یک فرایند مستمر برای حفظ پایداری، امنیت و عملکرد زیرساخت فناوری اطلاعات است. در این مقاله بررسی میکنیم پشتیبانی زیرساخت دیتاسنتر دقیقا شامل چه خدماتی است، چرا سازمانها به آن نیاز دارند و یک سرویس حرفهای پشتیبانی چه تفاوتی با رفع خرابیهای مقطعی دارد.
پشتیبانی زیرساخت دیتاسنتر مجموعهای از فعالیتهای فنی برای نگهداری، پایش، عیبیابی، بهینهسازی و توسعه اجزای مرکز داده است. این خدمات میتواند از سرور و استوریج تا شبکه، مجازیسازی، بکاپ و تجهیزات امنیتی را دربر بگیرد در یک دیتاسنتر استاندارد، هر بخش به بخش دیگری وابسته است. برای مثال اگر استوریج با مشکل مواجه شود، ماشینهای مجازی ممکن است دچار اختلال شوند. اگر سوئیچ اصلی از مدار خارج شود، ارتباط سرورها با یکدیگر یا کاربران قطع میشود و اگر سیستم مانیتورینگ بهدرستی تنظیم نشده باشد، تیم IT ممکن است دیرتر از زمان مناسب متوجه مشکل شود. به همین دلیل، پشتیبانی باید دیدی End-to-End داشته باشد؛ یعنی زیرساخت را بهعنوان یک مجموعه یکپارچه بررسی کند، نه تعدادی تجهیزات مستقل.
ممکن است یک سازمان برای راهاندازی Citrix هزینه قابل توجهی صرف سرور، شبکه، ذخیرهسازی و لایسنس کند، اما در نهایت تجربه کاربران به یک دستگاه کوچک روی میز آنها وابسته باشد. اگر این دستگاه نتواند قابلیتهای Citrix را بهدرستی ارائه کند، نتیجه میتواند تأخیر تصویر، مشکل در اتصال تجهیزات USB، اختلال صدا و تصویر یا تجربه کاربری نامطلوب باشد. به همین دلیل انتخاب زیروکلاینت مناسب Citrix فقط به این معنا نیست که در مشخصات یک دستگاه عبارت «Citrix Support» نوشته شده باشد. نوع Firmware، پشتیبانی از HDX، نسخه کلاینت، توان پردازشی Endpoint، کیفیت خروجی تصویر، شبکه و تجهیزات جانبی همگی در عملکرد نهایی موثر هستند. در این مقاله بررسی میکنیم زیروکلاینت Citrix چه ویژگیهایی باید داشته باشد و هنگام انتخاب Endpoint برای محیط Citrix به چه مواردی باید توجه کرد.
زیروکلاینت دستگاهی سبک برای دسترسی کاربران به منابع پردازشی متمرکز است. برخلاف کامپیوترهای معمولی که بخش عمده پردازش برنامهها را بهصورت Local انجام میدهند، در معماری VDI یا Virtual Desktop Infrastructure، پردازش اصلی در دیتاسنتر یا زیرساخت ابری انجام میشود. Endpoint در چنین معماریای بیشتر نقش رابط میان کاربر و محیط مجازی را برعهده دارد؛ یعنی تصویر و صدای Session را دریافت میکند و ورودیهایی مانند کیبورد، ماوس و تجهیزات جانبی را به محیط مجازی منتقل میکند. بنابراین، منظور از زیروکلاینت Citrix دستگاهی است که بتواند دسترسی مناسب و پایدار به دسکتاپها و برنامههای ارائهشده توسط زیرساخت Citrix را فراهم کند. نکته مهم این است که در بازار، اصطلاح Zero Client گاهی برای دستگاههای دارای Firmware یا سیستمعامل Embedded نیز استفاده میشود. بنابراین هنگام خرید بهتر است بهجای تکیه صرف بر عنوان تجاری دستگاه، معماری، Firmware و قابلیتهای واقعی آن بررسی شود.