تصور کنید در ابتدای یک روز کاری، ده‌ها کارمند هم‌زمان اعلام می‌کنند که نرم‌افزارهای سازمان کند شده‌اند، ارتباط با سرور قطع و وصل می‌شود و دسترسی به اینترنت نیز کیفیت همیشگی را ندارد. تیم IT از یک سو وضعیت سرورها را بررسی می‌کند و از سوی دیگر به سراغ سوئیچ‌ها، روترها و لینک‌های ارتباطی می‌رود؛ اما هنوز مشخص نیست مشکل دقیقا از کجاست. در چنین شرایطی، تفاوت میان یک زیرساخت سنتی و یک شبکه حرفه‌ای مشخص می‌شود. در شبکه‌ای که مانیتورینگ شبکه سازمانی به درستی پیاده‌سازی شده باشد، مدیر شبکه برای پیدا کردن مشکل مجبور نیست تک‌تک تجهیزات را بررسی کند. سیستم مانیتورینگ می‌تواند وضعیت تجهیزات، ترافیک، پهنای باند، تأخیر، خطاها و بسیاری از شاخص‌های دیگر را به‌صورت مداوم بررسی کند و حتی پیش از جدی شدن اختلال هشدار دهد.
امروزه شبکه بخش حیاتی بسیاری از کسب‌وکارهاست. از سیستم حسابداری و اتوماسیون گرفته تا تلفن تحت شبکه، مجازی‌سازی، سرویس‌های ابری و ارتباط میان شعب، همگی به عملکرد صحیح زیرساخت وابسته هستند. بنابراین مانیتورینگ شبکه دیگر یک قابلیت جانبی نیست؛ بلکه بخشی از مدیریت حرفه‌ای فناوری اطلاعات محسوب می‌شود.
مانیتورینگ شبکه سازمانی یا Enterprise Network Monitoring فرآیندی است که طی آن وضعیت تجهیزات، ارتباطات، سرویس‌ها و ترافیک شبکه به‌صورت پیوسته اندازه‌گیری و تحلیل می‌شود. هدف اصلی این فرآیند آن است که تیم فناوری اطلاعات بتواند به سه سؤال مهم پاسخ دهد: آیا تجهیزات و سرویس‌های شبکه در دسترس هستند؟ آیا عملکرد آن‌ها در محدوده طبیعی قرار دارد؟ و اگر مشکلی ایجاد شده است، علت اصلی آن چیست؟ برای رسیدن به این هدف، یک سیستم مانیتورینگ شبکه اطلاعات مختلفی را از تجهیزاتی مانند روتر، سوئیچ، فایروال، سرور، اکسس پوینت، ماشین مجازی و حتی سرویس‌های ابری دریافت می‌کند. این اطلاعات سپس در قالب نمودار، داشبورد، گزارش و هشدار در اختیار مدیر شبکه قرار می‌گیرد.
آیا برای استفاده از زیروکلاینت به یک شبکه بسیار پرسرعت نیاز داریم؟ این یکی از اولین سوالاتی است که هنگام راه‌اندازی زیرساخت 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 داشته باشد؛ یعنی زیرساخت را به‌عنوان یک مجموعه یکپارچه بررسی کند، نه تعدادی تجهیزات مستقل.