لودبالانسر برای Jira Data Center: چهار الزامی که نادیده گرفتنشان کلاستر جیرا را می‌شکند

Jira Data Center یعنی چند نود پشت یک لودبالانسر. تصور رایج این است که هر لودبالانسری کار می‌کند — و همین تصور، منبع بیشتر مشکلات عجیب کلاستر است: کاربری که مدام از سیستم بیرون می‌افتد، فایلی که آپلود می‌شود ولی پیدا نمی‌شود، و کندی‌ای که روی هیچ نموداری دیده نمی‌شود.

اطلسین چهار الزام مشخص دارد. اگر هر کدام رعایت نشود، کلاستر «کار می‌کند» ولی درست کار نمی‌کند — و خرابی‌اش به شکل خطا ظاهر نمی‌شود، به شکل رفتار عجیب ظاهر می‌شود.

الزام اول: session affinity کوکی‌محور روی JSESSIONID

این مهم‌ترین و بیشترین‌اشتباه‌شوندهٔ چهارتاست. سشن کاربر روی همان نودی است که اول با آن حرف زده. اگر درخواست بعدی به نود دیگری برود، آن نود کاربر را نمی‌شناسد.

خیلی‌ها affinity را بر اساس IP مبدأ تنظیم می‌کنند. این روی کاغذ کار می‌کند و در عمل نه — چون همهٔ کاربران یک شرکت پشت یک NAT هستند و از دید لودبالانسر یک IP واحدند. نتیجه: کل سازمان روی یک نود می‌نشیند و بقیهٔ نودها بیکارند.

چطور بفهمید affinity خراب است

لازم نیست حدس بزنید. یک یوزرنیم مشخص را روی access log هر نود جدا بگیرید:

# روی هر نود، جداگانه اجرا کنید
grep ' someuser ' /opt/atlassian/jira/logs/access_log.$(date +%F) \
  | tail -20

اگر همان کاربر در بازهٔ یک دقیقه روی بیش از یک نود دیده شد، affinity کار نمی‌کند. این تست سی ثانیه وقت می‌برد و جواب قطعی می‌دهد.

الزام دوم: health check باید بدنه را بخواند، نه فقط کد وضعیت

نود Jira در حال بالا آمدن می‌تواند HTTP 200 برگرداند در حالی که هنوز آمادهٔ سرویس‌دهی نیست. اگر لودبالانسر فقط کد وضعیت را ببیند، ترافیک را به نودی می‌فرستد که هنوز ایندکسش را باز نکرده.

چیزی که باید چک شود، endpoint وضعیت و محتوای پاسخ است:

GET /status

# پاسخ نود سالم:
{"state":"RUNNING"}

حالت‌های دیگری هم وجود دارد که همه با HTTP 200 برمی‌گردند ولی هیچ‌کدام آمادهٔ ترافیک نیستند — مثل STARTING و MAINTENANCE. پس شرط سلامت این است: کد ۲۰۰ و بدنه شامل RUNNING.

الزام سوم: draining تدریجی موقع خروج نود

وقتی می‌خواهید نودی را برای ارتقا یا ری‌استارت از سرویس خارج کنید، قطع ناگهانی یعنی هر کاربری که سشنش روی آن نود بوده، کارش را از دست می‌دهد. لودبالانسر باید بتواند نود را در حالت draining بگذارد: درخواست جدید نفرستد ولی سشن‌های موجود را تا پایان کار رها نکند.

این تنها راهی است که ارتقای بدون قطعی (rolling upgrade) واقعاً بدون قطعی باشد. بدون آن، هر بار ارتقا یک قطعی کوچک است که کاربران حسش می‌کنند.

الزام چهارم: SSL termination درست

معمولاً SSL روی لودبالانسر تمام می‌شود و ترافیک داخلی HTTP است. اگر این را به Jira نگویید، لینک‌هایی که می‌سازد http:// می‌شوند و مرورگر محتوای ترکیبی را بلاک می‌کند.

دو طرف کار دارد. سمت لودبالانسر، این دو هدر باید عبور کنند:

• X-Forwarded-For — تا IP واقعی کاربر در لاگ بیفتد، نه IP لودبالانسر
• X-Forwarded-Proto — تا Jira بداند کاربر با HTTPS آمده

سمت هر نود، connector در server.xml باید بداند از پشت پروکسی سرویس می‌دهد:

<Connector port="8080"
           protocol="HTTP/1.1"
           scheme="https"
           proxyName="jira.example.com"
           proxyPort="443"
           secure="true"
           ... />

نمونهٔ رسمی برای همهٔ لودبالانسرها وجود ندارد

این نکته را باید بدانید تا دنبال چیزی نگردید که نیست: اطلسین نمونهٔ پیکربندی فقط برای Apache mod_proxy_balancer و HAProxy منتشر کرده. اگر لودبالانسر شما چیز دیگری است — NGINX Plus، F5، یا لودبالانسر یک پلتفرم مجازی‌سازی — نمونهٔ آماده پیدا نمی‌کنید.

راه درست این است که به‌جای گشتن دنبال نمونه، همین چهار الزام را به‌عنوان چک‌لیست بردارید و روی هر پلتفرمی معادلشان را پیاده کنید. هر لودبالانسر جدی هر چهارتا را پشتیبانی می‌کند؛ فقط اسم گزینه‌ها فرق دارد.

مظنون دومی که همیشه فراموش می‌شود

اگر affinity درست است و هنوز کندی دارید، سراغ shared home بروید. همهٔ نودها یک فضای مشترک دارند — معمولاً روی NFS — که پیوست‌ها، ایندکس و پلاگین‌ها آنجاست.

تاخیر روی آن استوریج مستقیماً به کندی Jira تبدیل می‌شود، بدون اینکه CPU یا رم هیچ نودی بالا برود. این دقیقاً همان حالتی است که تیم‌ها را به اشتباه سراغ اضافه کردن منابع می‌فرستد. روش پیدا کردنش را در Jira کند شده کامل نوشته‌ام.

چک‌لیست قبل از تحویل کلاستر

1. affinity کوکی‌محور روی JSESSIONID — با تست access log تایید شده
2. health check روی /status با بررسی بدنه، نه فقط کد وضعیت
3. قابلیت draining برای خروج تدریجی نود
4. X-Forwarded-For و X-Forwarded-Proto عبور می‌کنند
5. scheme و proxyName و proxyPort روی connector هر نود تنظیم شده
6. Base URL دقیقاً با proxyName یکی است
7. تاخیر shared home اندازه‌گیری و مستند شده

جمع‌بندی

کلاستر Jira که غلط پیکربندی شده، خراب به نظر نمی‌رسد — فقط عجیب رفتار می‌کند. و چون هیچ خطای واضحی نمی‌دهد، تیم‌ها ماه‌ها با آن سر می‌کنند و اسمش را می‌گذارند «جیرا همینه دیگه».

هر چهار الزام قابل تست‌اند و تستشان چند دقیقه بیشتر طول نمی‌کشد. اگر می‌خواهید این بازبینی روی کلاستر خودتان انجام شود، پشتیبانی و نگهداری Jira شامل همین است. و اگر هنوز بین Cloud و Data Center مردد هستید، مقایسهٔ کامل دو نسخه را ببینید.