توضیح بار سرور VPN: کاربران، CPU یا پهنای باند بالادستی؟
امتیاز بار پایین می‌تواند یعنی کاربران بیکار، CPU اضافه یا پهنای باند بالادستی گسترده. پیش از سریع نامیدنش، loadavg، شمارنده‌های رابط و فایل وضعیت را بخوانید.
دروازه‌ای که روی بار 0.4 نشسته است باز هم می‌تواند برای هر کاربر پشتش کُند باشد. میانگین بار، وظایفی را می‌شمارد که قابل اجرا هستند یا در خواب غیرقابل‌قطع گیر کرده‌اند، و روی میزبان چهار هسته‌ای یک فرایند اشباع‌شده کافی است تا آن را به سمت 1.0 هل دهد، در حالی که سه هسته بیکار نشسته‌اند. خواندن این عدد به‌عنوان ظرفیت مازاد، رایج‌ترین اشتباه در انتخاب نقطه پایانی است. چیزی که واقعاً یک تونل را محدود می‌کند معمولاً یکی از چهار چیز است: یک هسته مشغول، پهنای باند بالادستی، صف جلوی آن، یا یک سیاست به‌ازای هر نشست که هیچ‌کس مستند نکرده است.
میانگین بار وظایف را می‌شمارد، نه توان عبوری
کرنل از صف اجرا و تعداد وظایفی که منتظر ورودی و خروجی هستند نمونه می‌گیرد، سپس هر دو را در بازه‌های یک، پنج و پانزده دقیقه هموار می‌کند. هیچ‌چیز در این تعریف از بایت، بسته یا تونل نام نمی‌برد. میزبانی که ذخیره‌سازی‌اش قفل شده می‌تواند بار بالا را با تقریباً هیچ ترافیکی گزارش کند، و میزبانی که یک گیگابیت را از مسیر داده کرنل عبور می‌دهد می‌تواند بار راحتی گزارش کند.
بنابراین مرتبط کردن بار با کارایی تونل نیازمند دید به‌ازای هر هسته است. اگر یک هسته اشباع شود، درصد تجمعی روی داشبورد هنوز خوب به نظر می‌رسد:
cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20دستور سوم مهم‌ترین دستور روی میزبان‌های VPN است. پردازش بسته در فضای کاربر در OpenVPN 2.x عمدتاً به‌ازای هر فرایند سریالی است، بنابراین یک ریسمان مشغول می‌تواند سقف شود در حالی که داشبورد ظرفیت بیکار فراوان گزارش می‌دهد. اگر یک ریسمان در دوره کندی شما بیشتر یک هسته را بگیرد، میزبان در کل کم‌تجهیز نیست؛ او در بُعدی محدود شده است که تصادفاً اهمیت دارد.
به زمان‌بندی هم توجه کنید. میانگین‌های پانزده‌دقیقه‌ای انفجاری را پنهان می‌کنند که یک تماس را خراب کرد، پس اسکرین‌شاتی که بعد از شکایت گرفته شده شاهد ضعیفی است. در حین مشکل نمونه بگیرید و برچسب زمان را همراه خروجی نگه دارید.
پهنای باند بالادستی و صف جلوی آن
شمارنده‌های رابط به پرسش پهنای باندی پاسخ می‌دهند که ارقام CPU نمی‌توانند. آن‌ها همچنین ظرفیت را از افت جدا می‌کنند، که نقص‌های متفاوتی با راه‌حل‌های متفاوت هستند:
ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmitپیوندی که در طول آزمون شما نزدیک به نرخ تخصیص‌یافته‌اش باشد توضیح است، و هیچ مقدار CPU اضافه‌ای آن را تغییر نمی‌دهد. خط qdisc جزئیاتی را اضافه می‌کند که برای ترافیک تعاملی مهم است: انباشت و افت‌ها به شما می‌گویند آیا بسته‌ها پیش از خروج در صف منتظر می‌مانند. صفی که زیر یک بارگذاری بزرگ پر می‌شود دقیقاً همان نشانه‌ای را تولید می‌کند که مردم سرور دور را سرزنش می‌کنند، یعنی تماس‌های کند روی اتصالی که در بنچمارک هنوز خوب عمل می‌کند.
شمارنده‌های بازفرست به حالتی می‌رسند که بسته‌ها خارج می‌شوند اما هرگز تمیز نمی‌رسند. اگر بازفرست‌ها در پنجره کندی بالا می‌روند و رابط به‌هیچ‌وجه نزدیک ظرفیت نیست، مشکل در مسیر است نه روی میزبان، و جابه‌جایی به نقطه پایانی دیگر در همان شهر کمکی نمی‌کند.
تعداد نشست‌ها تقاضا را توصیف می‌کند، نه ظرفیت مازاد
هر فهرست عمومی تعدادی کاربر متصل نشان می‌دهد و تقریباً هیچ‌کدام نمی‌گوید این کاربران چه می‌کنند. بیست نشست با کار تعاملی و چهار نشست که فایل‌های بزرگ می‌کشند بارهای بسیار متفاوتی روی همان سخت‌افزار تولید می‌کنند. الگوی دوم در تعداد کاربر نامرئی است و همان است که یک شب را خراب می‌کند. پس عدد نشست را بهتر است به‌عنوان نشانه‌ای از تقاضا بخوانید، هرگز به‌عنوان بیانیه‌ای درباره ظرفیت مازاد.
| Number on the page | What it is really measuring | What it cannot tell you |
|---|---|---|
| Connected users | How many sessions hold an address | How much each one is transferring |
| Load or score | Whatever the operator chose to publish | Whether that definition matches your task |
| Uptime | How long since the process started | Current capacity, queue depth or packet loss |
| Distance or ping | Round-trip time on a small probe | Throughput under sustained transfer |
روی میزبانی که خودتان کنترل می‌کنید، فایل وضعیت بُعد گمشده را می‌دهد. OpenVPN یک عکس لحظه‌ای دوره‌ای می‌نویسد که شمارنده‌های بایتی به‌ازای هر کلاینت را در بر می‌گیرد، و این کافی است تا ببینید آیا یک نشست مسئول تمام پهنای باند بالادستی است:
status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.statusدو نمونه با ده ثانیه فاصله آن شمارنده‌های تجمعی را به نرخی برای هر کلاینت تبدیل می‌کنند. این همان سنجشی است که تعداد کاربر جانشینش شده است، و همین‌طور کشف می‌کنید که یک کلاینت بدتنظیم هر شب در ساعت یکسان پیوند را اشباع می‌کند.
محدودیت‌های هر نشست در دل سیاست پنهان است
سرور می‌تواند بیکار باشد و باز هم از دادن پهنای باند به شما خودداری کند. محدودیت نرخ، سقف پهنای باند هر کلاینت و شکل‌دهی ترافیک اغلب بر اساس نام مشترک یا بر اساس مخزن اعمال می‌شوند، بنابراین دو کاربر روی همان دروازه می‌توانند نتایج کاملاً متفاوتی بگیرند. سازوکار ظریف نیست، اما از بیرون نامرئی است چون تونل در هر دو حالت عادی بالا می‌آید.
شکل‌دهی را روی رابط تونل بجویید نه روی رابط فیزیکی. بررسی کنید که محدودیت از کاربر، گواهی یا مخزن نشانی‌ها پیروی می‌کند. اگر حساب آزمون شما در مخزن بدون سقف بیفتد، نتیجه می‌گیرید که سرور سالم است و کاربر شاکی اشتباه می‌کند. این نتیجه‌گیری از نبود نتیجه‌گیری بدتر است، چون تیکت را می‌بندد.
دو نقطه پایانی را با یک وظیفه ثابت مقایسه کنید
آزمایش سمت کلاینت هنوز ارزش اجرا دارد، اما تنها اگر متغیرها ثابت شوند. از همان دستگاه، همان شبکه دسترسی، همان پروتکل و همان فایل مقصد استفاده کنید، سپس آن را در برابر نقطه پایانی دومی در فاصله مشابه تکرار کنید. هر چیزی که بین اجراها تغییر کند، از جمله ساعت روز، نتیجه را آلوده می‌کند.
شکست‌ها را به همان دقت موفقیت‌ها ثبت کنید. مجموعه‌ای که در آن سه نقطه پایانی کار می‌کنند و یکی به پایان زمان می‌رسد از چهار عدد سرعت گویاتر است، چون به مشکل مسیر یا سیاست اشاره دارد نه ظرفیت. هر مورد را دست‌کم دو بار اجرا کنید؛ یک نمونه کند در شبکه اشتراکی چیزی را اثبات نمی‌کند.
در پایان، عددهایی را که جمع کردید همراه با ادعایی که پشتیبانی می‌کنند نگه دارید. "این نقطه پایانی انتقال را در همان پنجره‌ای انجام داد که دیگری متوقف شد" قابل دفاع است، در حالی که "این نقطه پایانی سریع‌تر است" دعوتی به بحثی است که با امتیاز صفحه اصلی نمی‌توانید ببرید. راهنمای OpenVPN 2.6 فایل وضعیت و گزینه‌های شکل‌دهی را مستند می‌کند اگر به دستورهای دقیق سمت میزبان نیاز دارید.