SixAM

راهنمای بهینه‌سازی کارایی RDS

زیرساخت و مدیریت سیستم‌ها۱۸ خرداد ۱۴۰۵7 دقیقه مطالعه

مسئله

Remote Desktop Services (RDS) بی‌صدا افت می‌کند. کاربران تیکتی نمی‌زنند که «session broker نامتوازن است». می‌گویند «امروز کند است». تا وقتی شکایت‌ها به میز پشتیبانی برسد، علت معمولاً ساختاری است: session host کوچک، broker‌ای که همه را به یک سرور می‌فرستد، یا گلوگاه بارگذاری پروفایل هنگام ورود.

توضیح فنی

یک فارم RDS چند بخش متحرک دارد که هرکدام حالت خرابی خود را دارند:

  • Session host‌ها بار کاربران را حمل می‌کنند. CPU و بیشتر اوقات حافظه و I/O دیسک، محدودیت‌ها هستند.
  • Connection broker تصمیم می‌گیرد نشست جدید روی کدام host بنشیند. اگر توازن بار نادرست باشد، نشست‌ها روی یک host انباشته می‌شوند.
  • پروفایل کاربر (roaming، کانتینرهای FSLogix) هنگام ورود بارگذاری می‌شود. ذخیره‌ساز کند پروفایل به‌صورت ورودِ کند دیده می‌شود، نه برنامه‌ی کند.
  • مجوزدهی و gateway به‌ندرت مشکل کارایی می‌سازند اما در پیکربندی نادرست خرابی قطعی ایجاد می‌کنند.

بهترین روش‌ها

  • Host را برای بار کاری اندازه بگیرید، نه تعداد نفرات. کاربر کارهای ساده و کاربر CAD جایگزین هم نیستند. پیش از مقیاس‌دهی، کاربران نماینده را پروفایل و CPU/RAM واقعی هر نشست را اندازه بگیرید.
  • توازن بار broker را بررسی کنید. وزن نسبی session host‌ها را تنظیم و مطمئن شوید نشست‌های جدید واقعاً توزیع می‌شوند. broker‌ای که بی‌صدا یک host را ترجیح می‌دهد، رایج‌ترین علت کندی «تصادفی» است.
  • پروفایل‌ها را روی ذخیره‌ساز سریع بگذارید. کانتینرهای FSLogix روی اشتراک‌های SMB کند، گلوگاه کلاسیک ورود است. در اینجا تأخیر کم مهم‌تر از ظرفیت خام است.
  • سقف نشست هر host را تعیین کنید. حداکثری بگذارید تا یک host بیش از حد قابل‌استفاده بارگذاری نشود.
  • شمارنده‌های درست را پایش کنید. نشست‌های فعال هر host، طول صف پردازنده، حافظه‌ی در دسترس و میانگین زمان ورود را دنبال کنید، نه فقط درصد CPU.

یک نمونه‌ی واقعی

در یک فارم، کاربران از کندی متناوب بدون علت آشکار خبر می‌دادند؛ CPI هر host به‌طور میانگین خوب به نظر می‌رسید. شمار نشست هر host واقعیت را گفت: broker اکثریت نشست‌های جدید را به دو host می‌فرستاد در حالی که بقیه تقریباً بیکار بودند. وزن‌های نسبی پس از یک بازسازی منحرف شده بودند. اصلاح وزن‌های broker و افزودن سقف نشست برای هر host، توزیع را یکنواخت کرد و کندی «تصادفی» ناپدید شد، بدون خرید حتی یک سرور اضافه.

جمع‌بندی

کارایی RDS پیش از آنکه مسئله‌ی ظرفیت باشد، مسئله‌ی توازن است. مصرف منابع هر نشست را اندازه بگیرید، مطمئن شوید broker واقعاً توازن می‌دهد، پروفایل‌ها را روی ذخیره‌ساز سریع نگه دارید و زمان ورود را به‌عنوان معیار درجه‌یک پایش کنید. بیشتر کندی RDS مسئله‌ی توزیع یا پروفایل است، نه سرورِ کم. فهمیدن این موضوع در ابتدا، هزینه‌ی واقعی را ذخیره می‌کند.