یک سازمان صد نفره سرور جدید میخرد، پروژه دسکتاپ مجازی را اجرا میکند و دو هفته بعد کاربران شکایت دارند که سیستم از کیس قبلیشان کندتر است. سرور گران بوده، مشخصاتش روی کاغذ عالی است و هیچکس نمیفهمد مشکل کجاست.
این سناریو تکراریترین شکست پروژههای VDI است و تقریباً همیشه یک ریشه دارد: زیرساخت بر اساس مشخصات اسمی تجهیزات انتخاب شده، نه بر اساس رفتار واقعی کاربران. زیرساخت مورد نیاز VDI یک فهرست ثابت از سختافزار نیست؛ خروجی یک محاسبه است که ورودیاش تعداد کاربران و نوع کارشان است.
در این مقاله دقیقاً همان محاسبه را انجام میدهیم. با اعداد مرجع، با فرمول، و با یک مثال کامل که نشان میدهد یک سرور مشخص چند کاربر را واقعاً پوشش میدهد. اگر هنوز با مفهوم پایه آشنا نیستید، ابتدا مقاله VDI چیست را بخوانید.
زیرساخت مورد نیاز VDI شامل چه بخشهایی است؟
پیش از هر محاسبهای باید بدانیم چه چیزهایی را میخواهیم محاسبه کنیم. زیرساخت مورد نیاز VDI از این اجزا تشکیل میشود:
- سرورهای Compute: میزبان ماشینهای مجازی دسکتاپ
- CPU و RAM: تعیینکننده تعداد دسکتاپ روی هر Host
- Storage: هم از نظر ظرفیت، هم از نظر Performance
- شبکه: شبکه داخلی مرکز داده و مسیر ارتباطی کاربران
- Hypervisor: vSphere، Hyper-V، Proxmox یا مشابه
- پلتفرم مدیریت VDI: شامل لایه Broker که کاربر را به دسکتاپش وصل میکند
- Active Directory: برای احراز هویت و اعمال Group Policy
- مدیریت Profile و داده کاربران
- Backup و در صورت نیاز Disaster Recovery
- تجهیزات سمت کاربر: تین کلاینت، زیرو کلاینت یا کیسهای موجود سازمان
نکتهای که هزینه بسیاری از پروژهها را هدر داده این است: این لایهها با هم جمع نمیشوند، بلکه در هم ضرب میشوند. ضعف در هر کدام، سرمایهگذاری روی بقیه را بیاثر میکند. سرور قدرتمند با استوریج کند، تجربه کاربری بهتری از سرور متوسط با استوریج مناسب نمیسازد. اگر هنوز بین معماریهای مختلف تصمیم نگرفتهاید، مقایسه در تفاوت VDI و RDS نقطه شروع خوبی است، چون انتخاب معماری مستقیماً روی همین محاسبات اثر میگذارد.
سایزینگ VDI از کجا شروع میشود؟
اولین مرحله سایزینگ VDI انتخاب سرور نیست. اولین مرحله شناخت کاربر است. تا وقتی ندانید کاربران شما چه کاری انجام میدهند و چند نفرشان همزمان کار میکنند، هر عددی که برای سختافزار انتخاب کنید حدس است.
تعداد کاربر در VDI؛ کل یا همزمان؟
این رایجترین خطای محاسبه است. سازمانی که ۳۰۰ کارمند دارد، لزوماً به ظرفیت ۳۰۰ دسکتاپ همزمان نیاز ندارد. آنچه اهمیت دارد تعداد Concurrent User است: کاربرانی که در ساعت اوج، همزمان سشن فعال دارند.
در محیطهای اداری این نسبت معمولاً بین ۶۰ تا ۸۵ درصد کل کاربران است. در سازمانهای شیفتی، مراکز تماس و محیطهای آموزشی رفتار کاملاً متفاوت است و ممکن است در یک بازه کوتاه به نزدیک ۱۰۰ درصد برسد و در بقیه روز به ۲۰ درصد سقوط کند.
پس دو عدد را جدا کنید: تعداد کل کاربران برای محاسبه فضای Storage و لایسنس، و تعداد کاربران همزمان برای محاسبه CPU، RAM و IOPS.
دستهبندی کاربران بر اساس workload
سایزینگ با یک عدد میانگین برای همه کاربران تقریباً همیشه به یک نتیجه میرسد: کمبود منابع برای گروه سنگین و اتلاف منابع برای گروه سبک. کاربران را دستکم به سه گروه تقسیم کنید:
| گروه | نمونه کاربری | ویژگی مصرف |
|---|---|---|
| سبک | اتوماسیون اداری، آفیس، ایمیل، چند تب مرورگر | مصرف پایین و یکنواخت |
| متوسط | چند نرمافزار همزمان، مرورگر با تبهای زیاد، ویدئوکنفرانس | مصرف نوسانی با اوجهای کوتاه |
| سنگین | نرمافزار مهندسی، نقشهکشی، پردازش داده | مصرف بالا و پیوسته، اغلب نیازمند GPU |
یک راه عملی برای تعیین این نسبتها: بهجای حدس زدن، مصرف CPU و RAM چند کاربر نمونه از هر واحد سازمانی را برای یک هفته کاری ثبت کنید. یک هفته داده واقعی، از یک ماه بحث در جلسه دقیقتر است.
CPU مورد نیاز VDI چگونه محاسبه میشود؟
در محیط VDI، عدد تعیینکننده تعداد هسته سرور نیست؛ نسبت Overcommit است. یعنی نسبت مجموع vCPU اختصاصیافته به دسکتاپها، به تعداد هسته فیزیکی در دسترس.
دلیلش ساده است: هیچوقت همه کاربران همزمان پردازنده را اشباع نمیکنند. کاربری که در حال تایپ در Word است، عملاً چیزی از CPU مصرف نمیکند. همین اجازه میدهد چند دسکتاپ یک هسته فیزیکی را به اشتراک بگذارند.
برای کاربران اداری، نسبت ۳ به ۱ نقطه شروع متعادلی است. نسبتهای بالاتر مثل ۴٫۵ به ۱ در انتهای بالای طیف قرار دارند و با اولین اسکن آنتیویروس یا بروزرسانی همزمان، CPU Ready بالا میرود و کاربر مکث را احساس میکند. برای کاربران مهندسی و گرافیکی، نسبت باید محافظهکارانهتر باشد و در بسیاری از طراحیها به ۱ به ۱ نزدیک میشود.
هسته فیزیکی مورد نیاز = مجموع vCPU ÷ نسبت Overcommit
برای دسکتاپ اداری، تخصیص ۲ vCPU نقطه شروع رایجی است. تخصیص یک vCPU برای جایگزینی کامل یک کامپیوتر رومیزی توصیه نمیشود؛ کافی است یک اسکن آنتیویروس در پسزمینه اجرا شود تا کل سشن قفل شود. برای کاربر مهندسی، ۴ تا ۸ vCPU بسته به نرمافزار.
این مقدار کل ظرفیت مورد نیاز Host نیست. منابع Hypervisor، ماشینهای مجازی زیرساختی مثل Connection Broker و File Server، و ظرفیت Failover باید جداگانه به محاسبات اضافه شوند.
رم مورد نیاز VDI چقدر است؟
در بیشتر خوشههای VDI، حافظه زودتر از پردازنده به سقف میرسد. یعنی وقتی محاسبات CPU هنوز فضای کافی نشان میدهد، RAM عملاً محدودکننده واقعی چگالی است. به همین دلیل رم مورد نیاز VDI را باید جدیتر از CPU محاسبه کرد.
مصرف فعال حافظه بر اساس نوع کاربر معمولاً در این بازهها قرار میگیرد:
- کاربر اداری با مرورگر، ایمیل و آفیس: حدود ۲ تا ۳ گیگابایت مصرف فعال
- کاربر سنگین با ویدئوکنفرانس و تبهای زیاد مرورگر: حدود ۴ تا ۶ گیگابایت
- کاربر مهندسی و نقشهکشی: از ۸ گیگابایت به بالا، بسته به نرمافزار
به این مقدار باید سربار سیستمعامل، ایجنتهای امنیتی و ۱۵ تا ۲۵ درصد ذخیره برای رشد و رویدادهای پسزمینه اضافه شود. در عمل یعنی برای کاربر اداری معمولاً ۴ گیگابایت تخصیص میدهیم تا ۲ تا ۳ گیگابایت مصرف فعال با حاشیه امن پوشش داده شود.
یک توصیه که تفاوت زیادی میسازد: سایزینگ حافظه را بر اساس صدک ۹۵ مصرف مشاهدهشده انجام دهید، نه میانگین. میانگین، اوجهای کوتاه را پنهان میکند و نتیجهاش این است که در یک روز کاملاً عادی وارد Swap میشوید و کاربر کندی را به پای فناوری VDI مینویسد، نه به پای طراحی.
RAM کل Host = مقدار بالا + سربار Hypervisor + سرویسهای زیرساختی + ظرفیت Failover
استوریج مناسب VDI؛ جایی که بیشتر پروژهها شکست میخورند
اگر قرار باشد فقط روی یک لایه از زیرساخت دقت کنید، آن لایه Storage است. بیشترین سهم نارضایتی کاربران در پروژههای VDI از اینجا میآید، و بدترین بخشش این است که مشکل معمولاً در روز اول دیده نمیشود؛ وقتی تعداد کاربران به عدد واقعی میرسد خودش را نشان میدهد.
ظرفیت مورد نیاز
در محاسبه ظرفیت باید اینها لحاظ شوند: دیسک سیستمعامل ماشینهای مجازی، نرمافزارها، Golden Image، داده و پروفایل کاربران، فضای Snapshot در صورت استفاده، و فضای رشد آینده.
یک نکته که هزینه را به شکل قابل توجهی کم میکند: در معماری دسکتاپ غیرمستمر با Linked Clone یا Instant Clone، فضای مصرفی بهمراتب کمتر از ضرب ساده تعداد کاربران در حجم ایمیج است، چون همه دسکتاپها یک ایمیج پایه مشترک دارند و فقط تفاوتها ذخیره میشود.
IOPS در VDI؛ عددی که همه فراموش میکنند
IOPS یا Input/Output Operations Per Second، تعداد عملیات ورودی و خروجی Storage در هر ثانیه است. داشتن فضای کافی به معنی عملکرد مناسب نیست؛ استوریج باید بتواند الگوی I/O محیط را هم پاسخ بدهد.
رفتار I/O یک دسکتاپ مجازی در طول روز ثابت نیست و سه حالت کاملاً متفاوت دارد:
- بوت سیستمعامل: چند صد IOPS، عمدتاً خواندن
- لحظه ورود کاربر: حدود ۵۰ IOPS با نسبت تقریبی ۶۰ درصد خواندن
- کار عادی روزانه: حدود ۵ تا ۱۰ IOPS با نسبت حدود ۸۵ درصد نوشتن
همین تغییر نسبت خواندن و نوشتن است که باعث میشود استوریجی که برای بار خواندنی بهینه شده، در ساعات کاری عادی ضعیف عمل کند. محیطی که هنگام تست صبحگاهی عالی بود، ساعت یازده صبح کند میشود.
محاسبه IOPS برای VDI
راهنماهای رایج سایزینگ، برای برآورد اولیه در حالت پایدار این اعداد را پیشنهاد میکنند:
| نوع کاربر | IOPS پایدار هر کاربر | نمونه کاربری |
|---|---|---|
| سبک | ۴ | آفیس، ایمیل، اتوماسیون اداری |
| متوسط | ۸ | چند نرمافزار همزمان، مرورگر با تبهای زیاد |
| سنگین | ۱۲ | نرمافزار مهندسی، پردازش داده |
به این مقدار حدود ۲۵ درصد برای اوج ورود صبحگاهی اضافه میشود. مثال برای هزار کاربر، با فرض ۸۰ درصد سبک و ۲۰ درصد سنگین:
یعنی استوریج باید حدود ۷۰۰۰ IOPS با نسبت تقریبی ۱۵ درصد خواندن و ۸۵ درصد نوشتن را با Latency قابل قبول پاسخ بدهد. توجه کنید که در عمل، Latency اغلب مهمتر از خود عدد IOPS است؛ وقتی Latency بالا میرود کاربر مکث را احساس میکند حتی اگر گزارش IOPS طبیعی به نظر برسد.
Boot Storm و Login Storm در VDI؛ تصحیح یک باور رایج
Boot Storm در VDI زمانی رخ میدهد که تعداد زیادی ماشین مجازی تقریباً همزمان راهاندازی شوند و فشار خواندنی سنگینی روی Storage بسازند. Login Storm در VDI هم به دورهای گفته میشود که تعداد زیادی کاربر تقریباً همزمان وارد دسکتاپهای خود میشوند.
اما اینجا یک باور غلط رایج وجود دارد که باعث میشود سازمانها استوریج را بیش از نیاز بخرند. در عمل معمولاً تنها حدود ۳ تا ۵ درصد کاربران واقعاً همزمان لاگین میکنند. ورود ساعت هشت صبح در ذهن ما یک موج یکپارچه است، ولی در واقعیت روی ده تا پانزده دقیقه پخش میشود. به همین دلیل اوج ورود صبحگاهی در بیشتر محیطها حدود ۲۵ درصد IOPS اضافه ایجاد میکند، نه چند برابر شدن بار.
Boot Storm داستان متفاوتی دارد و بار خواندنی بهمراتب سنگینتری میسازد، ولی مزیتش این است که قابل زمانبندی است. اگر دسکتاپهای غیرمستمر دارید و هر شب بازسازی میشوند، این بازسازی باید بخشی از طراحی و خارج از ساعات اداری باشد، نه یک اتفاق در ساعت هشت صبح.
SSD و NVMe برای VDI
SSD و NVMe برای workloadهایی که به IOPS بالا و Latency پایین نیاز دارند گزینههای مناسبی هستند و در محیطهای VDI امروزی عملاً استاندارد شدهاند. با این حال انتخاب رسانه سریعتر بهتنهایی تضمینکننده عملکرد مطلوب نیست.
معماری کامل Storage شامل Controller، Cache و مسیر I/O هم باید بررسی شود. یک NVMe سریع پشت یک Controller اشباعشده، سرعتش را به کاربر نمیرساند. همچنین در محیطهایی با نوشتن سنگین، دوام دیسک بر حسب DWPD اهمیت پیدا میکند، چون بار نوشتن VDI مداوم است نه انفجاری.
پهنای باند مورد نیاز VDI چقدر است؟
برای کاربری اداری معمولی، ۱ تا ۲ مگابیت بر ثانیه به ازای هر کاربر بهعنوان ظرفیت اوج در نظر گرفته میشود. مصرف میانگین در طول روز بهمراتب کمتر است و اغلب زیر نیم مگابیت باقی میماند؛ عدد بالاتر برای پوشش لحظات اوج مثل اسکرول سریع، باز شدن پنجرهها و بازسازی کامل تصویر لازم است.
این عدد با موارد زیر افزایش پیدا میکند:
- Resolution بالاتر و استفاده از چند مانیتور
- پخش ویدیو و ویدئوکنفرانس داخل سشن
- نرمافزارهای گرافیکی و CAD
- ریدایرکت پرینتر، USB، صدا و انتقال فایل
شبکه مناسب VDI چه ویژگیهایی دارد؟
در طراحی شبکه مناسب VDI فقط ظرفیت لینک اهمیت ندارد. Latency، Packet Loss، Redundancy و ظرفیت Uplink هم باید بررسی شوند. یک لینک با پهنای باند کافی ولی Latency بالا، تجربه کاربری بدتری از یک لینک باریکتر با Latency پایین میسازد.
برای شعب راه دور این نکته تعیینکننده انتخاب پروتکل هم هست. پروتکلی که در شبکه محلی عالی کار میکند، ممکن است روی لینک بینشهری با Latency بالا نتیجه کاملاً متفاوتی بدهد. اگر سازمان شما چند شعبه دارد، تست پروتکل روی بدترین لینک باید بخشی از فاز طراحی باشد، نه چیزی که بعد از تحویل کشف شود.
ظرفیت سرور VDI چگونه محاسبه میشود؟
برای تعیین تعداد کاربر قابل پشتیبانی توسط یک سرور، نمیتوان صرفاً RAM یا تعداد هستهها را بر تعداد کاربران تقسیم کرد. باید هر دو منبع را جداگانه محاسبه کرد و کمترین مقدار را برداشت.
مثال کامل: یک سرور، چند کاربر؟
یک سرور دو سوکته با ۳۲ هسته فیزیکی و ۵۱۲ گیگابایت رم را در نظر بگیرید که قرار است کاربر اداری میزبانی کند، با تخصیص ۲ vCPU و ۴ گیگابایت رم به هر دسکتاپ:
| منبع | محاسبه | نتیجه |
|---|---|---|
| CPU | ۳۲ هسته × نسبت Overcommit ۳ ÷ ۲ vCPU | حدود ۴۸ دسکتاپ |
| RAM | (۵۱۲ منهای حدود ۶۴ سربار) ÷ ۴ | حدود ۱۱۲ دسکتاپ |
| محدودیت واقعی | کمترین مقدار بین دو ردیف بالا | حدود ۴۸ دسکتاپ |
در این مثال CPU زودتر از RAM به سقف رسیده و ظرفیت ۶۴ دسکتاپ از حافظه بلااستفاده مانده است. یعنی این سرور برای این workload، رم بیش از نیاز و پردازنده کم دارد. اگر پیش از خرید همین محاسبه انجام شده بود، با پردازنده قویتر و رم کمتر، هزینه کمتری با ظرفیت بیشتر به دست میآمد.
در بسیاری از سرورهای امروزی نتیجه دقیقاً برعکس میشود و RAM محدودکننده است. هیچ قاعده کلی وجود ندارد؛ به همین دلیل هر دو محاسبه باید انجام شود.
چرا Failover ظرفیت را تغییر میدهد
عدد ۴۸ هنوز ظرفیت قابل استفاده نیست. اگر خوشه شما باید در صورت خرابی یک Host هم سرویس بدهد، ظرفیت یک سرور کامل باید کنار گذاشته شود.
یعنی برای پوشش ۹۶ کاربر در معماری N+۱، به سه سرور نیاز دارید، نه دو تا. سازمانهایی که این را در بودجهریزی اولیه نمیبینند، معمولاً در فاز اجرا بین دو گزینه بد گیر میکنند: یا خرید سرور خارج از بودجه، یا پذیرش اینکه خرابی یک سرور نیمی از کاربران را از کار میاندازد.
مشخصات سرور VDI؛ سه پیکربندی نمونه
سؤال «سرور مناسب VDI چیست» جواب واحدی ندارد، ولی برای اینکه تصویری از ابعاد کار داشته باشید، سه پیکربندی نمونه برای کاربری اداری با تخصیص ۲ vCPU و ۴ گیگابایت رم:
| کاربر همزمان | سختافزار مورد نیاز VDI | Storage | معماری |
|---|---|---|---|
| تا ۵۰ | ۲ سرور، هر کدام ۱۶ تا ۲۴ هسته و ۲۵۶ گیگابایت رم | حدود ۳۵۰ IOPS، تمام فلش | N+۱ با دو Host |
| تا ۱۰۰ | ۳ سرور، هر کدام ۲۴ تا ۳۲ هسته و ۳۸۴ گیگابایت رم | حدود ۷۰۰ IOPS، تمام فلش | N+۱ با سه Host |
| تا ۲۰۰ | ۵ سرور، هر کدام ۳۲ هسته و ۵۱۲ گیگابایت رم | حدود ۱۴۰۰ IOPS، استوریج مشترک | N+۱ یا N+۲ |
این اعداد فرض میکنند کاربران همگی سبک هستند. حضور حتی ۲۰ درصد کاربر مهندسی، تعداد سرورها را بهطور محسوسی تغییر میدهد و اگر آن کاربران به GPU نیاز داشته باشند، معماری کاملاً متفاوتی لازم است.
پیش از محاسبه منابع VDI چه اطلاعاتی جمع کنیم؟
محاسبه منابع VDI بدون این دادهها ممکن نیست. این فهرست را پیش از هر جلسه فنی تکمیل کنید:
اطلاعات کاربران
- تعداد کل کاربران و تعداد کاربران همزمان در ساعت اوج
- گروههای کاری و سهم هر گروه از کل
- ساعات اوج مصرف و الگوی شیفت
- تعداد شعب و کیفیت لینک هر شعبه
اطلاعات نرمافزارها
- نرمافزارهای آفیس و مرورگرها
- نرمافزارهای سازمانی، مالی و اتوماسیون اداری
- نرمافزارهای مهندسی و گرافیکی
- نرمافزارهای ویدئوکنفرانس
- نرمافزارهای نیازمند قفل سختافزاری یا توکن امضای دیجیتال
اطلاعات زیرساخت فعلی
- Hypervisor، سرورها، Storage و شبکه موجود
- ساختار Active Directory و مدیریت Profile
- وضعیت فعلی Backup و Monitoring
چهار اشتباه رایج در فاز طراحی زیرساخت VDI
انتخاب سرور فقط بر اساس CPU
پردازنده قدرتمند بهتنهایی عملکرد مناسب را تضمین نمیکند. همانطور که در مثال بالا دیدید، در بسیاری از پیکربندیها یکی از RAM یا Storage محدودکننده واقعی است، نه CPU.
محاسبه بر اساس تعداد کل کاربران
سایزینگ بر اساس عدد کل بهجای کاربر همزمان، تقریباً همیشه به تخصیص بیش از نیاز و هزینه اضافه منجر میشود.
نادیده گرفتن IOPS
Storage ممکن است از نظر ظرفیت کافی باشد اما Performance لازم برای الگوی I/O محیط را نداشته باشد. این رایجترین علت نارضایتی کاربران است و بدترین ویژگیاش این است که اصلاح آن پس از خرید، گرانترین اصلاح ممکن است.
طراحی بدون ظرفیت Failover
اگر تمام ظرفیت محیط به Hostهای فعال وابسته باشد، خرابی یک Host تعداد کاربران قابل پشتیبانی را کاهش میدهد. ظرفیت مورد نیاز در سناریوی خرابی باید از ابتدا در بودجه دیده شود.
اعتبارسنجی محاسبات با تست واقعی
محاسبات اولیه یک برآورد قابل اتکا میدهند، اما رفتار واقعی کاربران همیشه با فرضیات یکسان نیست. یک نرمافزار سازمانی ممکن است CPU بیشتری مصرف کند، نرمافزار دیگری RAM بیشتری بخواهد و گروهی از کاربران فشار غیرمنتظرهای روی Storage بسازند. یک تست محدود با کاربران واقعی پیش از نهایی شدن sizing، ارزانترین بیمهنامه این پروژه است.
چکلیست سایزینگ VDI
| بخش | سؤالی که باید پاسخ داده شود |
|---|---|
| کاربران | چند کاربر کل و چند کاربر همزمان در ساعت اوج داریم؟ |
| Workload | سهم هر گروه کاربری چقدر است و چه نرمافزارهایی اجرا میکنند؟ |
| CPU | هر دسکتاپ چند vCPU میگیرد و نسبت Overcommit چقدر است؟ |
| RAM | مصرف فعال هر گروه در صدک ۹۵ چقدر است؟ |
| Storage | ظرفیت مورد نیاز با احتساب رشد و نوع Clone چقدر است؟ |
| IOPS | در حالت پایدار و در اوج ورود، چه میزان I/O لازم است؟ |
| Latency | استوریج در بار اوج چه Latencyای ارائه میدهد؟ |
| Network | پهنای باند، Latency و Packet Loss مسیر کاربران چقدر است؟ |
| HA | در صورت خرابی یک Host چه میزان ظرفیت باقی میماند؟ |
| Backup | کدام اجزای محیط باید Backup شوند؟ |
| DR | برای خرابی سایت اصلی چه سناریویی وجود دارد؟ |
| Test | آیا workload واقعی پیش از نهایی شدن sizing تست شده است؟ |
جمعبندی
زیرساخت مورد نیاز VDI یک مشخصات سختافزاری ثابت نیست. طراحی درست با شناخت workload کاربران شروع میشود و سپس CPU، RAM، Storage، IOPS، شبکه و ظرفیت Hostها بر اساس همان workload تعیین میشوند.
اگر بخواهیم کل این مقاله را در سه عدد خلاصه کنیم: تعداد کاربران همزمان، مصرف فعال حافظه در صدک ۹۵، و IOPS مورد نیاز در بار اوج. این سه عدد بیشترین اثر را روی نتیجه نهایی دارند و اگر درست برآورد شوند، بقیه محاسبات نسبتاً مستقیم است.
و یک اصل که ارزش تکرار دارد: در محاسبه ظرفیت هر سرور، همیشه کمترین مقدار بین CPU و RAM را بردارید و سپس ظرفیت Failover را از آن کم کنید. همین دو قدم ساده، اکثر پروژههایی را که به کندی و نارضایتی ختم میشوند، از ابتدا نجات میدهد.
اگر برای تعیین ظرفیت منابع، انتخاب معماری و طراحی زیرساخت VDI سازمان خود نیاز به بررسی تخصصی دارید، تیم سهند ارتباطات هوشمند امکانسنجی و سایزینگ اولیه را بهصورت رایگان انجام میدهد.
