پیکربندی بروکر

Artemis اجازه می‌دهد address settingها، security settingها و divertهای یک بروکرِ در حال اجرا را از راه API مدیریت تغییر دهید و این تغییرها را پس از راه‌اندازی مجدد نگه می‌دارد. این هم مفید است و هم یک دام: هیچ‌چیز در بروکر ثبت نمی‌کند که این تغییر رخ داده، پس بروکرِ در حال اجرا و broker.xml‌ای که دفعهٔ بعد از روی آن مستقر می‌شود بی‌سروصدا با هم اختلاف پیدا می‌کنند.

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

اعلامیه چیست

چهار بخش، یک سند برای هر کلاستر، با یک نسخه به ازای هر ذخیره:

بخش	اعمال با آن چه می‌کند
Addressها و صف‌ها	آنچه را که نیست می‌سازد. هرگز حذف نمی‌کند. صفی که با پیکربندی متفاوت وجود دارد گزارش می‌شود، تغییر نمی‌کند — از نمای Queues ویرایشش کنید.
Address settingها	به ازای هر match: سقف‌ها، سیاست‌ها، address نامهٔ مرده و انقضا، بازتحویل. اعمال، کل ورودی بروکر برای آن match را جایگزین می‌کند.
Security settingها	به ازای هر match: کدام نقش‌ها می‌توانند بفرستند، مصرف کنند، بسازند و مدیریت کنند.
Divertها	هرجا نباشد ساخته می‌شود؛ divert تغییریافته یک حذف و یک ساخت است.

باقی broker.xml — global-max-size، <ha-policy>، acceptorها و مانند آن — در هیچ نسخه‌ای از Artemis از راه API مدیریت قابل اعمال نیست. وارد کردن فایلی که این‌ها را دارد هرکدام را به‌عنوان اعمال‌نشده فهرست می‌کند؛ چیزی برایشان ذخیره نمی‌شود و وانمود هم نمی‌شود.

دو راه اعمال

حالت برای هر کلاستر در سرصفحهٔ اعلامیه تعیین می‌شود و هر دو کنش همیشه دیده می‌شوند:

• مدیریت‌شده توسط Studio. پیش‌نمایش و اعمال اعلامیه را از راه API مدیریت روی هر نود فعال می‌نویسد. تغییر پس از راه‌اندازی مجدد می‌ماند و ارزیابی بعدی انحراف، نودها را همگام نشان می‌دهد.
• مدیریت‌شده بیرون از Studio. کپی قطعهٔ broker.xml اعلامیه را به‌شکل چهار بخشِ یک عنصر <core> برای مدیریت پیکربندی خودتان رندر می‌کند. اعمال غیرفعال است و دلیلش را می‌گوید. انحراف همچنان ارزیابی می‌شود، پس می‌فهمید استقرارتان مطابق است یا نه.

Studio هرگز broker.xml را نمی‌نویسد و هرگز reloadConfigurationFile را صدا نمی‌زند — بارگذاری مجدد، کل فایل را از دیسک بروکر دوباره می‌خواند، از جمله ویرایش‌هایی که Studio هرگز ندیده؛ دقیقاً همان نوع کنشی که قابل پیش‌نمایش نیست.

گرفتن نخستین اعلامیه

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

Studio هرگز خودسرانه نمی‌پذیرد. پذیرش یعنی اعلام اینکه هر چیزی که بروکرها همین حالا اتفاقاً اجرا می‌کنند خواسته بوده است — از جمله تنظیمی که کسی یک ساعت پیش دستی عوض کرده و هنوز دربارهٔ آن به نتیجه نرسیده است. تنها یک اپراتور می‌تواند چنین چیزی بگوید، و به همین دلیل انحراف تا وقتی کسی آن را نگوید فقط توصیه می‌ماند (ADR-0067 D8) و این هم یک پیشنهاد است نه رفتار پیش‌فرض.

سه راه ورود از نمای Configuration:

1. پذیرش از کلاستر هر نود فعال را می‌خواند و از آنچه اجرا می‌کنند اعلامیه می‌سازد. هر match از address settingها با ورودی کاملی که بروکر گزارش می‌کند پر می‌شود، پس نخستین اعمال چیزی را تغییر نمی‌دهد. هرجا نودها اختلاف دارند هر دو مقدار فهرست می‌شود و شما انتخاب می‌کنید.

2. وارد کردن XML: یک broker.xml یا قطعه‌ای از آن را بچسبانید — عنصرهای <address-setting> و <security-setting> بدون پوشش هم پذیرفته می‌شوند. پیش‌نمایش آنچه شناخته شد (به ازای هر بخش: افزوده / تغییریافته / بی‌تغییر)، آنچه اعمال نمی‌شود و خطاها را با نام عنصر فهرست می‌کند — جای‌نگهدار حل‌نشدهٔ ${…} خطاست، نه مقدار. به‌طور پیش‌فرض متن چسبانده‌شده در آنچه از قبل اعلام شده ادغام می‌شود: ورودی‌های چسبانده‌شده به همتای خود افزوده می‌شوند یا آن را به‌روز می‌کنند و در یک address setting کلیدهای چسبانده‌شده برنده‌اند و بقیهٔ کلیدهای اعلام‌شده می‌مانند. جایگزینی متن چسبانده‌شده را کل اعلان می‌کند.

   دفتر قابلیت‌ها در صفحهٔ راه‌اندازی و تنظیمات کلاستر از همین در وارد می‌شود. هرجا قطعهٔ «نیاز به راه‌اندازی» یک address یا security setting باشد — تشخیص مصرف‌کنندهٔ کند، مجوز اعلان‌ها، سقف اندازهٔ پیام مدیریتی — همان ردیف این را می‌گوید و اعلام در پیکربندی را پیشنهاد می‌دهد که پیش‌نمایش وارد کردن را روی همان قطعه باز می‌کند. نیمهٔ ایستای چنین قطعه‌ای (بلوک <broker-plugins>) اعمال‌نشده فهرست می‌شود و همچنان به broker.xml نیاز دارد.

3. افزودن یک ورودی در هر بخش. ویرایشگرها با فهرستی از تمام کلیدهای address setting که بروکر می‌پذیرد اعتبارسنجی می‌کنند: کلید ناشناخته رد می‌شود، نه اینکه روی بروکر به یک بی‌عملیِ خاموش تبدیل شود. هر کلید یک دکمهٔ اطلاعات دارد که می‌گوید چه چیزی را کنترل می‌کند و یک مقدار نمونه می‌دهد، و دنبالهٔ بلند پشت کلیدهای دیگر یک جست‌وجوگر دارد.

یک چیز را بروکر نمی‌تواند به Studio بگوید: نوع‌های مجوز view و edit در یک security setting از راه مدیریت پذیرفته می‌شوند اما هرگز بازگزارش نمی‌شوند (روی 2.44 اندازه‌گیری شد). فرستاده می‌شوند، از برنامه، تأیید و بررسی انحراف کنار گذاشته می‌شوند و ویرایشگر این را می‌گوید — آن دو را در پیکربندی خود بروکر تأیید کنید.

هر ذخیره یک نسخهٔ تازه است. دو اپراتور که هم‌زمان ویرایش می‌کنند روی هم نمی‌نویسند: ذخیره می‌گوید بر پایهٔ کدام نسخه انجام شده و اگر آن نسخه جابه‌جا شده باشد رد می‌شود.

بستن شکاف‌های قابلیت

بخشی از آنچه دفتر قابلیت‌ها آن را کمبود گزارش می‌کند اصلاً پیکربندی ایستا نیست: address setting یا security settingای است که API مدیریت همان لحظه می‌پذیرد. زبانهٔ Recommended آن‌ها را به اعلامیه‌ای تبدیل می‌کند که می‌توانید اعمال کنید، به‌جای قطعه‌ای که باید بروید و بچسبانید (ADR-0068).

امروز سه مورد قابل اعمال است — بازگرداندن بدنهٔ کامل پیام‌ها به Studio (management-message-attribute-size-limit)، تشخیص مصرف‌کنندهٔ کند، و مجوز activemq.notifications. هرکدام به‌صورت ورودی کاملی که نود همین حالا اجرا می‌کند نشان داده می‌شود و کلیدهای پیشنهادی روی آن تغییر کرده‌اند، چون نوشتن در زمان اجرا کل ورودی را جایگزین می‌کند و در آن ادغام نمی‌شود: آنچه صفحه فهرست می‌کند دقیقاً همان چیزی است که نود پس از آن خواهد داشت. نقش‌های پیشنهادی یک security setting از خود بروکر خوانده می‌شوند و پیش از اعلام قابل ویرایش‌اند؛ بلوکی که هیچ نقشی را نام نبرد رد می‌شود، چون تمیز اعمال می‌شود و به هیچ‌کس چیزی نمی‌دهد.

بقیه — افزونهٔ اعلان‌ها، acceptor، و security setting مدیریت — هیچ عملیات مدیریتی پشتشان نیست و نخواهد بود. آن‌ها با broker.xml و دلیلشان نام برده می‌شوند، نه حذف.

اعلام کردن یک نسخهٔ معمولی با منبع RECOMMENDED ذخیره می‌کند — پس ردِ حسابرسی می‌گوید از کجا آمده — و شما را به برنامه می‌برد. تا وقتی آن اعمال را مثل هر اعمال دیگری تأیید نکنید، چیزی به بروکر نمی‌رسد. یک پیشنهاد به‌محض اینکه کاوشگر بتواند اثرش را بازبخواند ناپدید می‌شود؛ به همین دلیل فقط همین سه مورد پیشنهاد می‌شوند: پیشنهادی که Studio نتواند «انجام‌شده» بودنش را ببیند هرگز از بین نمی‌رود.

هنگام ثبت کلاستر، بررسی اتصالِ موفق همین پنل را پیش‌نمایش می‌دهد و پس از ساخته‌شدن کلاستر شما را به آن می‌برد.

پیش‌نمایش و اعمال

جریان اعمال «برنامه ← تأیید ← نتیجه» است و طوری ساخته شده که نتواند یک‌باره کل کلاستر را از کار بیندازد.

برنامه. یک اجرای آزمایشی هر نود هدف را می‌خواند — حداکثر دو درخواست دسته‌ای برای هر نود، هرگز یکی به ازای هر مورد — و برای هر نود، گام‌های مرتبی را که وضعیت مشاهده‌شده‌شان با اعلامیه فرق دارد محاسبه می‌کند. گامی که بازخوانی‌اش از پیش مطابق است همان‌طور که اعلام شده است و نوشتنی صادر نمی‌کند. ترتیب درون هر نود: addressها ← صف‌ها ← address settingها ← security settingها ← divertها؛ حذف‌ها پس از افزودن‌ها. هر گام مثل یک تفاوت خوانده می‌شود: یک ردیف برای هر کلید، قبل ← بعد، کلیدهایی که تغییر می‌کنند بالا و کلیدهایی که همان نوشتن نیز با خود می‌برد — چون نوشتن مدیریتی کل ورودی را جایگزین می‌کند — کم‌رنگ در پایین. پس معنای جایگزینی دیده می‌شود و نه حدس زده: کلیدی که اعلام نکرده‌اید ولی به‌هرحال تغییر می‌کند یک خطر بالا با نام تغییر ناخواستهٔ کلید است. هنگام پیمایش گام‌ها یک نوار خلاصه روی صفحه می‌ماند: چند نوشتن، روی چند نود، کدام اول می‌رود و چه چیزی هنوز تصدیق نشده است. در کلاسترهای بزرگ بخش هر نود جمع می‌شود؛ قناری و هر نودی که شکست خورده همیشه باز است. تراشه‌ها نما را بر پایهٔ بخش یا کلید فیلتر می‌کنند — شمارها و شماره‌های گام همان‌های خودِ برنامه می‌مانند.

خطرها پیش از هر نوشتنی دسته‌بندی می‌شوند. خطرهای بالا باید هرکدام، با شناسه، روی برنامه تصدیق شوند:

خطر	چه وقت
تغییر ناخواستهٔ کلید	معنای جایگزینی کلیدی را که اعلامیه تعیین نکرده بازنشانی می‌کند
سیاست از دست رفتن پیام	address-full-policy روی matchی با addressهای مشاهده‌شده DROP یا FAIL می‌شود
سیاست مسدودکننده	address-full-policy می‌شود BLOCK
سقف کمتر از مصرف	سقف تازه از آنچه addressی زیر آن match هم‌اکنون دارد کمتر است
دسترسی مدیریت	یک security setting آدرس مدیریت را می‌پوشاند، یا match برابر # / * است
match گسترده	match برابر # یا * — هر address روی بروکر
حذف اعلام‌نشده	خودتان انتخاب کرده‌اید چیزی را که Studio اعمال نکرده حذف کنید

خطرهای متوسط و پایین (divert جایگزین‌شده، DLQ جابه‌جاشده، حذف خودکار فعال‌شده، مورد متعلق به Studio حذف‌شده) بیان می‌شوند و تصدیق نمی‌خواهند.

تأیید. شعاع اثر دوباره گفته می‌شود — چند نوشتن، روی کدام نودها، اول قناری — و شما نام کلاستر را تایپ می‌کنید. تصدیق خطرها تأیید کردن نیست؛ هر دو لازم است. عمداً هیچ دکمه‌ای نام را برایتان پر نمی‌کند: کلیکی که نام را می‌نویسد، تأیید تایپی را دوباره به یک کلیک دوم تبدیل می‌کند.

بازگشت به برنامه و برگشتن، تصدیق‌های شما را نگه می‌دارد. رفتن به تأیید ابتدا دوباره برنامه‌ریزی می‌کند و هش را می‌سنجد: اگر در این میان نودی تغییر کرده باشد، کلاستر تغییر کرده — این یک برنامهٔ تازه است را می‌بینید، با تفاوت روی صفحه و تصدیق‌های پاک‌شده، به‌جای یک ۴۰۹ که پس از تایپ کردن نام به شما برسد.

نتیجه. نخستین نود فعال (قناری؛ در برنامه می‌توانید دیگری را برگزینید) همهٔ گام‌ها را می‌گیرد و پیش از آنکه به هر نود دیگری دست زده شود بازخوانی می‌شود. و شما این را می‌بینید: تا وقتی اعمال در جریان است، هر نود گزارش می‌دهد کجاست — در حال اعمال، گام n از m، در حال بازخوانی برای راستی‌آزمایی، انجام‌شده یا متوقف — پس توقف روی قناری بی‌درنگ دیده می‌شود و شبیه یک موفقیتِ کند به نظر نمی‌رسد. آنچه نتیجه را اعلام می‌کند همچنان پاسخ همان درخواست است؛ خط زمانی فقط راهنماست. سپس اجرا نود به نود ادامه می‌یابد و در نخستین شکست متوقف می‌شود: گام‌های باقی‌ماندهٔ آن نود و همهٔ نودهای باقی‌مانده تلاش‌نشده می‌شوند. چیزی به عقب برنمی‌گردد و نتیجه در یک جمله همین را می‌گوید:

Halted at broker-1 step 3: AMQ229001 … broker-2 not attempted. Nothing was rolled back. Re-running converges.

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

هر اعمال، از جمله اجراهای آزمایشی، یک رویداد ممیزی است با نتیجهٔ نود × گام پیوست‌شده. سقف گام‌ها (config.apply-step-cap، پیش‌فرض ۱۰۰) برنامهٔ بزرگ‌تر را رد می‌کند مگر با اجازهٔ صریح، که ثبت می‌شود.

آنچه اعمال هرگز نمی‌کند

• نابود کردن صف یا address. حذف از اعلامیه فقط باعث می‌شود Studio دیگر آن را بررسی نکند. حذف واقعی، جریان خودِ صف است با سقف انبوهش.
• حذف چیزی که خودش اعمال نکرده. Studio آنچه را اعمال کرده ثبت می‌کند. setting یا divertی روی نود که اعلامیه از آن نامی نبرده اعلام‌نشده گزارش می‌شود؛ حذفش انتخابی جداگانه در هر برنامه با خطر بالای خودش است، چون اگر broker.xml هم آن را داشته باشد، حذف در راه‌اندازی مجدد بعدی برمی‌گردد و Studio نمی‌تواند بفهمد.
• اجرا با زمان‌بند. ارزیابی انحراف زمان‌بندی‌شده است؛ اعمال هرگز. یک قاعده می‌تواند روی انحراف هشدار دهد (CONFIG_DRIFT)؛ هیچ‌چیز به جای شما عمل نمی‌کند.

انحراف

هر نود فعال بر پایهٔ زمان‌بندی (config.drift-interval، پیش‌فرض پنج دقیقه)، پس از هر اعمال و در صورت درخواست، با نسخهٔ جاری سنجیده می‌شود. یک خواندن دسته‌ای و محدودشده برای هر نود؛ ارزیابی هرگز چیزی را تغییر نمی‌دهد.

زبانهٔ Drift با وضعیت نهایی در یک جمله آغاز می‌شود — All 3 live nodes match revision 7 — و سپس می‌گوید این اندازه‌گیری چند وقت پیش انجام شده و با چه آهنگی انجام می‌شود: Last evaluated 2m ago · evaluated about every 5m. یک مدت‌زمان به‌تنهایی نمی‌تواند «تازه ارزیابی شد» را از «زمان‌بند ایستاده است» جدا کند، پس این دو هرگز جدا نشان داده نمی‌شوند؛ زمان مطلق روی همان برچسب و با صفحه‌کلید در دسترس است و هر نود نشان وضعیت و مدت‌زمان خودش را دارد. با پایان هر ارزیابی و هر اعمال، زبانه خودش را به‌روز می‌کند، بدون بارگذاری دوباره.

وقتی چیزی فرق دارد، یافته‌ها به تفکیک نوع گروه‌بندی می‌شوند و مقدار اعلام‌شده و مشاهده‌شده در یک ردیف برای هر کلید می‌آیند، با نام نود در هر ردیف:

یافته	معنا
ناموجود	اعلام‌شده، روی نود نیست
متفاوت	روی نود هست با مقادیر متفاوت
اعلام‌نشده	روی نود هست، در اعلامیه نیست (فقط وقتی گزارشش برای کلاستر روشن باشد)
صف متفاوت	صف اعلام‌شده با پیکربندی متفاوت وجود دارد — از نمای Queues ویرایشش کنید
غیرقابل تأیید	کلیدی که بروکر گزارش نمی‌کند
دسترس‌ناپذیر — ارزیابی‌نشده	نود پاسخ نداد؛ نبودن به‌عنوان واقعیت گزارش نمی‌شود

نودهای پشتیبان ارزیابی نمی‌شوند: تا فعال نشوند settingهای زمان اجرا را نشان نمی‌دهند و address settingها، security settingها و divertها را از راه همانندسازی می‌گیرند. پشتیبانی که ارتقا یافته به‌محض فعال شدن ارزیابی می‌شود.

Config diff دو نود را با هم مقایسه می‌کند؛ انحراف هر نود را با اعلامیه. این دو به هم پیوند دارند.

مجوزها

مجوز	می‌دهد
cluster:read	دیدن اعلامیه، انحراف، تاریخچه؛ ارزیابی هم‌اکنون
config:write	ذخیرهٔ نسخه‌ها، وارد کردن، پذیرش، تغییر حالت
config:apply	پیش‌نمایش و اعمال

config:apply اختیارِ ساخت و به‌روزرسانی است: هرگز به معنای حذف صف یا address نیست. نقش مدیر داخلی همهٔ مجوزها را دارد؛ دو مجوز config:* را همان‌طور که queue:create یا divert:write را می‌دهید به نقش اپراتور بدهید.

از راه MCP

broker_config اعلامیه، انحراف، قطعهٔ XML یا تاریخچهٔ اعمال را می‌خواند. broker_config_change اعلام می‌کند (از سند یا از XML) یا اعمال می‌کند: اجرای آزمایشی — پیش‌فرض — برنامه را با خطرها و شناسه‌های دقیق acknowledge برمی‌گرداند؛ اجرای واقعی نیاز دارد confirm برابر نام کلاستر و expectedPlanHash برابر هش پیش‌نمایش باشد، و دقیقاً مثل رابط کاربری متوقف می‌شود. ببینید سرور MCP.

چگونه تصمیم گرفته شد

ADR-0067 دوازده تصمیم پشت این صفحه و گزینه‌های ردشده را ثبت کرده — ویرایشگر XML آزاد، reloadConfigurationFile، پخش کامل، یک هماهنگ‌کنندهٔ خودکار.