خوشه های خود تعادل

استقرار بسترهای نرم افزاری تلاقی می تواند صدها کارگزار را اداره کند ، هزاران موضوع را مدیریت کند و در هر ساعت میلیاردها پیام تولید کند. کارگزاران هر روز می میرند ، موضوعات جدید ایجاد می شود و حذف می شوند و پارتیشن ها باید مجدداً تنظیم شوند تا بار کار را متعادل کنند. این می تواند تیم هایی را که وظیفه مدیریت عملیات زمان اجرا پلتفرم را دارند ، اضافه کنند.

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

• تعادل بار کاملاً خودکار
• نظارت خودکار خوشه ها برای عدم تعادل بر اساس مجموعه بزرگی از پارامترها ، تنظیمات و متغیرهای زمان اجرا
• معیارهای مداوم جمع آوری و برنامه های تعادل مجدد ، در بیشتر موارد به طور فوری تولید می شود و به صورت خودکار اجرا می شود
• تحریک اتوماتیک عملیات regalance بر اساس تنظیمات ساده ای که در مرکز کنترل مخلوط یا در سرور Kafka تنظیم کرده اید. فایلهای Properties. شما می توانید فقط در صورت اضافه شدن کارگزاران یا هر زمان ، که برای هر بار ناهموار تعادل می یابد ، تعادل خودکار را انتخاب کنید.
• دید در یک نگاه به وضعیت خوشه های شما ، و استراتژی و پیشرفت تعادل خودکار از طریق چند معیار کلیدی

چگونه خود تعادل عملیات کافکا را ساده می کند

خود تعادل مدیریت عملیاتی خوشه های کافکا را از این طریق ساده می کند:

• هنگامی که بار موجود در خوشه به طور ناموزون توزیع می شود ، خود متعادل به طور خودکار پارتیشن ها را برای بهینه سازی عملکرد دوباره تغییر می دهد
• هنگامی که یک کارگزار جدید به خوشه اضافه می شود ، خود متعادل به طور خودکار آن را با پارتیشن ها پر می کند
• هنگامی که می خواهید یک کارگزار را حذف کنید ، می توانید از کارگزاران kafka-remove برای خاموش کردن کارگزار و تخلیه پارتیشن ها از آن استفاده کنید
• هنگامی که یک کارگزار برای مدت مشخصی کاهش یافته است ، خود متعادل به طور خودکار پارتیشن ها را به سایر دلالان تغییر می دهد

متعادل کردن خود در مقابل Auto Data Balancer¶

خود تعادل مزایای زیر را نسبت به متعادل کننده داده های خودکار ارائه می دهد

• تعادل خوشه ای به طور مداوم کنترل می شود به طوری که هر زمان که لازم باشد ، تعادل اجرا می شود
• شرایط خرابی کارگزار به طور خودکار شناسایی و مورد بررسی قرار می گیرد
• هیچ ابزار اضافی برای اجرا (ساخته شده در کارگزاران)
• با مرکز کنترل تلاقی کار می کند و یک API REST ارائه می دهد
• بسیار سریع تر تعادل (چندین سفارش از بزرگی)

چگونه کار می کند

خوشه های خود تعادل آگاهی بار کافکا را بهینه می کنند. استفاده از منابع در یک خوشه می تواند ناهمگن باشد. کافکا خارج از جعبه یک فرآیند خودکار برای بهبود تعادل خوشه ارائه نمی دهد ، بلکه نیاز به محاسبه دستی در مورد نحوه تنظیم مجدد پارتیشن ها دارد.

خود تعادل این فرآیند را با جابجایی داده ها به گسترش بار خوشه ای به طور مساوی ساده می کند. خود تعادل معنای "یکنواخت" را بر اساس اهداف داخلی تعریف می کند ، اگرچه می توانید از طریق تنظیمات ورودی اختیاری را ارائه دهید.

معماری یک خوشه خود متعادل

کارگزاران کافکا معیارها را جمع می کنند و داده ها را به یک موضوع داخلی در مورد کنترل کننده تغذیه می کنند ، که در کارگزار سرب برای خوشه است. بنابراین ، کنترلر نقش مهمی در تعادل خوشه ایفا می کند. شما می توانید از کنترلر به عنوان گره ای که خود متعادل در آن اجرا می شود فکر کنید.

معیارها پردازش می شوند و تصمیمات بر اساس اهداف اتخاذ می شوند.

این داده ها برای نظارت و اقدامات بالقوه ، مانند تولید یک برنامه تعادل بار یا ایجاد یک تعادل ، به سایر موضوعات داخلی کافکا تغذیه می شوند.

شما می توانید با استفاده از دستور kafka-topics-در حالی که پلت فرم تلاقی در حال اجرا است ، تمام مباحث ، از جمله موضوعات داخلی را مشاهده کنید ، به عنوان مثال: kafka-topics-لیست-bootstrap-server localhost: 9092. مباحث داخلی خود متعادل با _confluent_balancer_ پیشوند می شوند.

فعال کردن خوشه های خود تعادل

• برای هر کارگزار موجود در خوشه خود ، confluent. balancer. enable = درست برای فعال کردن خود تعادل و اطمینان حاصل کنید که این خط از بین نرود. پلتفرم های تلاقی با مجموعه خود متعادل در پرونده به عنوان مثال فعال می شوند: $ confluent_home/etc/server. properties. برای کسب اطلاعات بیشتر ، به confluent. balancer. enable مراجعه کنید.
• برای دسترسی به خود تعادل برای پیکربندی و نظارت از مرکز کنترل ، خوشه مرکز کنترل را با نقاط پایانی استراحت پیکربندی کنید تا سرورهای HTTP روی کارگزاران فعال شود ، همانطور که در تنظیمات مورد نیاز برای مرکز کنترل توضیح داده شده است.

چه چیزی یک خوشه "متعادل" را تعریف می کند و چه چیزی باعث تعادل می شود؟

در یک سطح بالا ، خود متعادل بین دو نوع عدم تعادل تمایز قائل می شود:

• اقدامات عملیاتی عمدی ، مانند اضافه کردن یا حذف کارگزاران. در این موارد ، خود تعادل باعث صرفه جویی در زمان و مراحل دستی اپراتور می شود که در غیر این صورت مورد نیاز است.
• عملیات خوشه ای مداوم (مانند موضوع داغ یا پارتیشن). این تعادل در طول زندگی خوشه ادامه دارد.

این نقشه ها به دو گزینه پیکربندی سطح بالا که با خود متعادل دارید فعال کنید:

• فقط وقتی یک کارگزار اضافه می شود ، دوباره تعادل برقرار کنید
• تعادل در هر زمان (برای هر بار ناهموار ، از جمله تغییر در تعداد کارگزاران موجود)

مورد اول واضح است. در صورت اضافه شدن کارگزاران ، خود درمانی برای توزیع مجدد داده ها به کارگزار جدید یا داده های بارگیری از کارگزار مفقود شده رخ می دهد.

مورد دوم ظریف تر است. برای دستیابی به تعادل خوشه و داده های مداوم ، خوشه های خود متعادل در تعدادی از اهداف بهینه می شوند و همچنین در صورت عدم تعادل ، عملکرد خوشه ای را بهبود نمی بخشد. اهداف شامل ملاحظاتی برای قرار دادن و ظرفیت ماکت ، عوامل تکثیر و توان ، معیارهای متعدد در مورد موضوعات و پارتیشن ها ، رهبری ، آگاهی از قفسه ، استفاده از دیسک و ظرفیت ، استفاده از پردازنده و ظرفیت ، توان شبکه در هر کارگزار ، اهداف بیشمار توزیع بار و موارد دیگر است.

خوشه های خود متعادل کننده از نظارت مداوم و جمع آوری داده ها برای ردیابی عملکرد در برابر این اهداف استفاده می کنند و برنامه هایی را برای تعادل ایجاد می کنند. یک تعادل ممکن است بر اساس پیامدهای تمام عوامل وزنی برای توپولوژی در یک لحظه معین انجام شود یا نباشد. علاوه بر این ، الگوریتم متعادل تقریبی است و تحت تأثیر عوامل توضیح داده شده در بالا قرار دارد.

در هر دو مورد ، این خوشه همچنین هنگامی که یک کارگزار با درخواست کاربر (یا از خط فرمان یا مرکز کنترل) حذف می شود ، یا اگر یک کارگزار برخی از دوره های زمانی را از دست بدهد (همانطور که توسط confluent. balancer. heal. broker مشخص شده است ، از بین می رود. شکست. threshold. ms).

بنابراین ، حتی با تعادل خود تعادل فقط هنگامی که یک کارگزار اضافه شود ، این خوشه برای کارگزاران گمشده تعادل برقرار می کند ، مگر اینکه شما به طور عمدی خواص را برای جلوگیری از این امر تنظیم کنید (به عنوان مثال ، اگر confluent. balancer. heal. broker. failure. threshold. msرو ی-1 تنظیم شده است).

برای کسب اطلاعات بیشتر در مورد تعادل تعامل با قفسه ها و قرار دادن ماکت ، به تنظیمات قرار دادن ماکت و تنظیمات قفسه مراجعه کنید.

چه اتفاقی می افتد اگر کارگزار سرب (کنترل کننده) برداشته شود یا گم شود؟

در یک خوشه چند کارگزار ، یکی از کارگزاران رهبر یا کنترل کننده است و نقش مهمی در خود تعادل دارد (همانطور که در معماری یک خوشه خود متعادل توضیح داده شده است). چه اتفاقی می افتد اگر کارگزار جایی که کنترلر در آن کار می کند عمداً برداشته شود یا خراب شود؟

• هیچ تاثیری در یکپارچگی خوشه وجود ندارد.
• هنگامی که کنترلر برداشته یا از بین می رود ، یک کنترلر جدید انتخاب می شود.
• درخواست حذف کارگزار پس از انجام آن ادامه دارد. اگر کارگزار دیگری به کنترل کننده تبدیل شود ، کنترل کننده جدید روند حذف کارگزار را دوباره شروع و از سر می گیرد ، احتمالاً با تأخیر.
• رهبر جدید درخواست کارگزار حذف را انتخاب کرده و آن را تکمیل می کند.
• اگر کارگزار سرب در طی یک عملیات در حال پیشرفت "افزودن کارگزار" از بین برود ، عملیات "افزودن کارگزار" کامل نخواهد شد و به صورت ناموفق مشخص می شود. اگر کنترلر جدید این مورد را انتخاب نکند ، ممکن است لازم باشد کارگزاری را که می خواهید اضافه کنید دوباره راه اندازی کنید.

برای کسب اطلاعات بیشتر در مورد این موضوعات ، به عیب یابی مراجعه کنید.

چگونه کارگزاران کنترل کروز را کنترل می کنند؟

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

تعادل خود چه موضوعات داخلی ایجاد و استفاده می کند؟

مباحث داخلی خود را در پیکربندی و مرجع دستورات مشاهده کنید.

محدودیت ها¶

• تعادل خود از JBOD پشتیبانی نمی کند (فقط یک دسته از دیسک ها) ، همچنین به عنوان Spaing شناخته می شوند تا چندین دیسک را به عنوان یک ظاهر کنند. خود متعادل کردن فقط از تنظیمات با یک نقطه کوه منطقی واحد در معرض سیستم عامل پشتیبانی می کند ، مانند آن می توان در یک گره دیسک منفرد یا (توصیه می شود) یک آرایه اضافی از دیسک های مستقل 10 (RAID 10) حاصل شود. برای کسب اطلاعات بیشتر ، به دیسک های تحت اجرای Kafka در تولید مراجعه کنید.
• اگر یک کارگزار تنها ماکت یک پارتیشن را داشته باشد ، خود تعادل تلاش های انتخابی برای حذف کارگزار را برای جلوگیری از از دست دادن داده های احتمالی مسدود می کند (عملیات حذف کارگزار از بین می رود). بهترین راه برای اصلاح این امر ، افزایش عوامل تکثیر در موضوعات و مباحث داخلی در مورد کارگزاری است که می خواهید حذف کنید ، همانطور که در پیکربندی فاکتورهای تکثیر برای تعادل خود در آموزش شرح داده شده است.
• تلاش برای حذف یک کارگزار بلافاصله پس از راه اندازی خوشه ای (در حالی که خود تعادل در حال شروع است) می تواند به دلیل معیارهای کافی ناکام باشد و تلاش برای حذف کارگزار سرب نیز می تواند در مرحله دیگری شکست بخورد. راه حل این است که پس از یک دوره زمانی ، دوباره کارگزار را دوباره امتحان کنید. اگر کارگزار یک کنترلر است ، باید حذف کارگزار را از خط فرمان اجرا کنید ، زیرا ممکن است در مرکز کنترل موجود نباشد. برای کسب اطلاعات بیشتر ، ببینید که تلاش حذف کارگزار در هنگام اولیه سازی خود متعادل در عیب یابی انجام می شود.

پیکربندی و نظارت

خوشه های خود تعادل خود مدیریت می شوند و در حالی که خوشه در حال اجرا است ، می توانند فعال شوند. در بیشتر موارد ، شما نباید با پیش فرض ها دست و پنجه نرم کنید. به سادگی قبل یا بعد از شروع خوشه ، خود تعادل خود را فعال کنید و به آن اجازه دهید در صورت لزوم تعادل خودکار را انجام دهد.

در پرونده Server. Properties که با بستر های نرم افزاری Clonfuence ارسال می شود ، Confluent. Balancer. Ebable روی True تنظیم شده است ، این بدان معنی است که خود تعادل روشن است.

گرفتن وضعیت در متعادل

با شروع با شرکت های تجاری 6. 2. 0 ، API ها و دستورات برای به دست آوردن دید در وضعیت و عملکرد خود ویژگی خود متعادل ارائه شده است. برای کسب اطلاعات بیشتر ، به نظارت بر متعادل با خوشه Kafka-Releance مراجعه کنید.

با استفاده از مرکز کنترل

• برای دسترسی به تعادل خود از مرکز کنترل ، باید خوشه مرکز کنترل را با نقاط انتهایی استراحت پیکربندی کنید تا سرورهای HTTP روی کارگزاران فعال شود ، همانطور که در تنظیمات مورد نیاز برای مرکز کنترل توضیح داده شده است.
• اطلاعات در مورد کار با خود متعادل در مرکز کنترل نیز آموزش خود متعادل و راهنمای کاربر مرکز کنترل است.
• شما نمی توانید در هنگام استقرار با تلاقی برای Kubeetes (CFK) خود تعادل خود را از طریق مرکز کنترل مدیریت کنید. برای کسب اطلاعات بیشتر در مورد استفاده از Confluent برای Kubeetes برای مدیریت خود متعادل ، به خوشه های مقیاس کافکا و داده های تعادل در مستندات CFK مراجعه کنید.

شما می توانید این تنظیمات خود متعادل کننده را از مرکز کنترل تلاقی (http: // localhost: 9021/) تغییر دهید در حالی که خوشه در حال اجرا است:

• تعادل خود را روشن یا خاموش کنید. در پرونده Server. Properties که با بستر های نرم افزاری Clonfuence ارسال می شود ، Confluent. Balancer. Ebable روی True تنظیم شده است ، این بدان معنی است که خود تعادل روشن است.(به confluent. balancer. enable مراجعه کنید.)
• مقدار پیش فرض دریچه گاز (10485760 یا 10 مگابایت در ثانیه) را نادیده بگیرید ، که حداکثر پهنای باند شبکه موجود را برای تعادل خود تعیین می کند.(confluent. balancer. throttle. bytes. per. second)
• شرایط ماشه را برای تعادل تنها در صورت اضافه شدن کارگزاران (پیش فرض) یا هر زمان ، تغییر دهید.(confluent. balancer. heal. uneven. load. trigger)

تنظیمات به روز شده به مرحله اجرا گذاشته می شود و در برگه خود متعادل کننده منعکس می شود.

برای مشاهده نام املاک برای تنظیمات خود متعادل در اثر (در حالی که ویرایش یا نظارت بر آنها) ، نمایش پیکربندی های خام را انتخاب کنید.

خصوصیات و دستورات سرور کافکا

علاوه بر خصوصیات پویا که در بالا توضیح داده شد ، پارامترهای تنظیم بیشتر در $ confluent_home/etc/kafka/server. properties در معرض قرار می گیرند. اینها در گزینه های پیکربندی و دستورات برای خوشه های خود متعادل ، به طور خاص در تنظیمات زیرنویس و خود متعادل در کارگزاران شرح داده شده است. برای به روزرسانی بقیه این تنظیمات ، باید کارگزاران را متوقف کرده و خوشه را خاموش کنید.

به عنوان نمونه ای از نحوه راه اندازی و اجرای یک آزمایش سریع تعادل خود با حذف یک کارگزار و نظارت بر تعادل ، به آموزش خود تعادل خود مراجعه کنید. این مثال راهنمایی در مورد پیکربندی مناسب فاکتورهای تکثیر و نمایشی فرمان خاص خود متعادل ، کارگزاران kafka-remove را ارائه می دهد.

معیارهای نظارت بر یک تعادل

بستر های نرم افزاری تلاقی چندین معیار را از طریق پسوندهای مدیریت جاوا (JMX) در معرض دید قرار می دهند که برای نظارت بر بازپرداخت های آغاز شده توسط خود متعادل مفید هستند:

• نرخ بایت ورودی و خروجی برای انتصاب مجدد توسط kafka ردیابی می شود. Server: Type = BrokertopicMetrics ، Name = RevignmentBytesInpersec و Kafka. Server: Type = Brokertopicmetrics ، Name = ReasignmentBytesOutpersec. این معیارها توسط هر کارگزار گزارش شده است.
• تعداد وظایف در حال تعادل در حال تعادل در حال تعادل توسط kafka. databalancer ردیابی می شود: نوع = مجری ، نام = تکرار در انتظار و kafka. databalancer: نوع = مجری ، نام = ماکت-عمل در-پیش رفتن . این معیارها از کارگزار با نمونه متعادل داده فعال (کنترل کننده) گزارش شده است.
• حداکثر تاخیر پیرو در هر کارگزار توسط kafka. server ردیابی می شود: type = replicafetchermanager ، name = maxlag ، clientid = ماکت. تغییر مجدد پارتیشن ها باعث می شود این متریک به مقداری متناسب با اندازه پارتیشن پرش کند و سپس با پیشرفت مجدد به آرامی پوسیده شود. اگر این مقدار به آرامی افزایش یابد و نه به آرامی با گذشت زمان ، دریچه گاز تکثیر خیلی کم است.

شما می توانید لیست کامل معیارهای مربوط به بستر های نرم افزاری را در نظارت بر کافکا با JMX مشاهده کنید.

مستندات Apache Kafka® معیارهای گزارش و نظارت را با استفاده از نقاط پایانی JMX در اینجا پوشش می دهد.

برای نظارت بر تعادل خود ، قبل از شروع خوشه ، متغیر محیط JMX_PORT را تنظیم کنید ، سپس معیارهای گزارش شده را با استفاده از ابزارهای نظارت معمول خود جمع کنید. Jmxtrans ، Graphite و Grafana ترکیبی محبوب برای جمع آوری و گزارش معیارهای JMX از Kafka هستند. Datadog یکی دیگر از راه حل های نظارتی محبوب است.

تنظیمات ماکت و تنظیمات قفسه

ملاحظات زیر در مورد همه Revalances اعمال می شود.

قفسه

• قفسه ها دامنه گسل برای کافکا هستند. همه کارگزاران در یک قفسه در برابر شکست همزمان آسیب پذیر هستند. هر دو خوشه کافکا و خود متعادل از دانش مربوط به شناسه های قفسه برای قرار دادن مباحث ، در ابتدا (کافکا) و در هنگام تعادل (خود تعادل) استفاده می کنند.
• اگر کارگزاران شناسه های قفسه را اختصاص داده اند ، تلاش می کند تا ماکت ها به طور مساوی در قفسه ها توزیع کنند. به طور خاص ، خود تعادل تلاش می کند تا اطمینان حاصل کند که هیچ قفسه بیش از 1 ماکت بیشتر از یک پارتیشن نسبت به سایر قفسه ها ندارد. از آنجا که این برای تحمل گسل است ، اگر خود متعادل نتواند به تعادل یک رک برسد ، به هیچ وجه هیچ گونه تعادل را امتحان نمی کند.
• قفسه ها باید تقریباً برابر با کارگزاران بر روی آنها باشند. این امر به ویژه در صورت وجود قفسه های بسیار کمی در خوشه شما مهم است. حداقل ، تعداد کارگزاران در هر قفسه باید حداقل به اندازه تعداد مورد انتظار ماکت در هر قفسه باشد.

قرار دادن ماکت و خوشه های چند منطقه ای

• اگر از هر دو خوشه چند منطقه ای و خوشه های خود متعادل استفاده می کنید ، باید قفسه کارگزار را در همه کارگزاران مجموعه کارگزاران خود و هر کارگزاری که با خودکشی خود را فعال می کنید ، مشخص کنید ، باید یک منطقه یا قفسه مشخص شده برای کارگزار باشد. در هر یک از پرونده های Server. properties.
• از قوانین قرارگیری ماکت برای خوشه های چند منطقه استفاده می شود و تعریف "قفسه" را اضافه می کند تا جایی که می توان ماکت ها را قرار داد محدود شود. قرار دادن ماکت فقط زمانی کار می کند که قفسه ها برای همه کارگزاران فراهم شود.
• اگر قوانین قرارگیری ماکت برای یک موضوع مشخص شده باشد ، این امر بر سیاست استاندارد آگاهی از قفسه غلبه می کند.
• خود تعادل به سرعت به تغییرات در قوانین قرار دادن ماکت پاسخ می دهد و به صورت پیشگیرانه ماکت ها را در صورت لزوم برای برآورده کردن آن قوانین قرارگیری حرکت می دهد.
• اگر خود تعادل نتواند جایگاه های ماکت را برآورده کند ، هیچگونه تعادل انجام نمی دهد. برای شناسایی این موضوع ، خرابی های اشکال زدایی را مشاهده کنید.
• تعادل خود به راحتی می تواند ماکت ها را در قفسه ها جابجا کند تا زمانی که این کار باعث آگاهی از قفسه نشود. این می تواند منجر به هزینه های بالای شبکه برای انتصاب مجدد و تکثیر مداوم شود ، بنابراین خوشه های چند منطقه باید قوانین قرار دادن را برای همه موضوعات موجود در خوشه مشخص کنند.

ظرفیت¶

خود تعادل سعی می کند تا اطمینان حاصل کند که کارگزاران از ظرفیت میزبان تجاوز نمی کنند و بنابراین ، ماکت ها را از کارگزاران اضافه بار دور می کنند. ظرفیت کارگزار از نظر معیارهای زیر اندازه گیری می شود:

کارگزاران ظرفیت ماکت نباید بیش از این بسیاری از ماکت ها میزبان باشند (10،000 پیش فرض ؛ می توانند توسط confluent. balancer. disk. max. max. replicas) کارگزاران ظرفیت دیسک نباید دیسک های خود را فراتر از این نقطه پر کنند (پیش فرض 85 ٪ ، می تواند توسط تلاقی نادیده گرفته شود. balancer. disk. max. load) شبکه بایت در داخل و خارج (اختیاری)

میزان ترافیک شبکه کارگزار نباید از این بایت فراتر رود. به طور پیش فرض این مقدار بسیار بالا تنظیم شده است (long. max_value) بنابراین خود تعادل به طور پیش فرض ، هرگز به دلیل بار بیش از حد شبکه ، ماکت را از کارگزار خارج نمی کند. اگر می خواهید از ظرفیت شبکه برای ایفای نقش در تعادل خود استفاده کنید ، می توانید confluent. balancer.network. in. max. bytes. per. second و confluent. balancer.network. out. max. bytes. per. second را تنظیم کنید.

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

توزیع

تلاش های خود متعادل برای اطمینان از توزیع حتی ماکت ها و استفاده از دیسک در سراسر خوشه اما با برخی از احتیاط ها:

• هر دو ماکت و استفاده از دیسک تقریباً در حدود 20 درصد (٪) متعادل می شوند. طبیعی است که حتی پس از تعادل ، طیف وسیعی از استفاده از ماکت ها / دیسک را در سراسر کارگزاران مشاهده کنید.
• تعادل مصرف دیسک فقط زمانی اتفاق می افتد که حداقل یک کارگزار بیش از 20 درصد از ذخیره دیسک خود را استفاده کند.
• این اهداف توزیع منابع از اولویت پایین تر از سایر اهداف است و در صورت نیاز به نقض آگاهی از قفسه ، قرار دادن ماکت یا محدودیت ظرفیت ، برآورده نمی شود.
• تلاش خود برای تعادل برای تعادل (زیر ظرفیت) استفاده از شبکه و توزیع رهبر ، اما اینها باعث تعادل نمی شوند. برای توزیع منابع ناهموار ، فقط تعداد ماکت و استفاده از دیسک بالاتر از 20 درصد عوامل موثر است.

اشکال زدایی در مورد خرابی مجدد تعادل

اگر خود متعادل کننده به دلیل آگاهی از قفسه ، قرار دادن ماکت یا مشکلات ظرفیت نتواند تعادل برقرار کند ، منجر به بهینه سازی FailureException می شود که باید در ورود به سیستم کارگزار خود متعادل (که همان کنترل کننده خوشه است) قابل مشاهده باشد. جستجوی این استثنا ممکن است به شناسایی چنین مشکلاتی کمک کند.

ملاحظات امنیتی ¶

اگر در حال تعادل خود با پیکربندی امنیتی هستید ، باید احراز هویت را برای نقاط پایانی استراحت روی کارگزاران پیکربندی کنید. بدون این تنظیمات در پرونده های ویژگی های کارگزار ، مرکز کنترل در یک محیط امن به خود متعادل نخواهد بود.

اگر از کنترل دسترسی مبتنی بر نقش (RBAC) استفاده می کنید ، کاربر در تعادل خود در مرکز کنترل باید دارای نقش RBAC SystemAdmin در خوشه Kafka باشد تا بتواند کارگزاران را اضافه یا حذف کند و دیگر تعادل خود را انجام دهدوظایف مرتبط

برای اطلاعات در مورد تنظیم امنیت در بستر های نرم افزاری ، به بخش های روش های تأیید اعتبار ، کنترل دسترسی مبتنی بر نقش ، RBAC و ACL و آموزش امنیتی مراجعه کنید.

برای کسب اطلاعات در مورد تنظیم امنیت در بستر های نرم افزاری ، به بررسی اجمالی امنیتی ، آموزش امنیتی و مروری بر روشهای تأیید اعتبار مراجعه کنید. همچنین ، نسخه ی نمایشی پلت فرم تلاقی اسکریپت شده ، انواع مختلفی از امنیت را که در یک نمونه از آن فعال شده است ، نشان می دهد.

عیب یابی¶

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

علاوه بر نکات عیب یابی در زیر ، برای بهترین روشها ، تنظیمات ماکت و تنظیمات قفسه را مشاهده کنید ، بحث بیشتر در مورد آنچه باعث ایجاد مجدد تعادل می شود ، و نحوه شناسایی و اشکال زدایی شکست های تعادل.

گزینه های تعادل خود در مرکز کنترل ظاهر نمی شوند

When Self-Balancing Clusters are enabled, status and configuration options are available on Control Center Cluster Settings>برگه خود متعادل. اگر در عوض ، این برگه پیامی راجع به الزامات نسخه پلت فرم Confluent و پیکربندی سرورهای HTTP بر روی کارگزاران نشان می دهد ، این نشان می دهد چیزی از تنظیمات شما وجود ندارد یا اینکه نسخه مورد نیاز پلت فرم Confluent را اجرا نمی کنید.

همچنین ، اگر در حال انجام خود متعادل با امنیت فعال هستید ، ممکن است یک پیام خطا مانند: خطای 504 Gateway Timeout دریافت کنید ، که نشان می دهد شما همچنین باید احراز هویت را برای نقاط پایانی در پرونده های کارگزار خود پیکربندی کنید ، همانطور که در زیر توضیح داده شده است.

راه حل: تأیید کنید که تنظیمات زیر را دارید و پیکربندی خود را در صورت لزوم به روز کنید.

• در پرونده های کارگزار Kafka ، Concluent. Balancer. Enable باید درست تنظیم شود تا تعادل خود را فعال کند.
• در پرونده ویژگی های مرکز کنترل ، confluent. controlcenter. streams. cprest. url باید URL مرتبط را برای هر کارگزار در خوشه به عنوان نقاط پایانی استراحت برای ControlCenter. cluster مشخص کند ، همانطور که در تنظیمات مورد نیاز برای مرکز کنترل توضیح داده شده است.
• امنیت یک الزام برای تعادل خود نیست اما اگر امنیت فعال شود ، باید تأیید اعتبار را برای نقاط پایانی استراحت روی کارگزاران پیکربندی کنید. در این حالت ، شما می توانید از confluent. metadata. server. listeners (که سرویس ابرداده را امکان پذیر می کند) به جای confluent. http. server. listeners برای گوش دادن به درخواست های API برای یادگیری بیشتر استفاده کنید ، به ملاحظات امنیتی مراجعه کنید.
• خوشه های شما باید در سیستم عامل تلاقی 6. 0. 0 یا بعد از آن مستقر شوند.

معیارهای کارگزار در مرکز کنترل نمایش داده نمی شوند

این مسئله مخصوص تعادل خود نیست ، بلکه به طور کلی مربوط به پیکربندی مناسب خوشه های چند کارگزار است. شما ممکن است با سناریویی روبرو شوید که خود متعادل شده باشد و گزینه های خود متعادل را در مرکز کنترل نمایش دهید ، اما معیارهای کارگزار و مته های مته در هر کارگزار و گزینه های مدیریت در صفحه نمای کلی کارگزاران نمایش داده نمی شوند. محتمل ترین علت این امر این است که شما گزارشگر معیارها را برای مرکز کنترل پیکربندی نکردید. برای انجام این کار ، خطوط زیر را در پرونده های Properties برای همه کارگزاران نادیده بگیرید. به عنوان مثال ، در $ confluent_home/etc/server. properties:

متریک.=io. confluent. metrics. reporter. confluentmetricsreporter confluent. metrics. reporter. bootstrap. servers=LocalHost: 9092

راه حل: برای رفع این مسئله در خوشه های در حال اجرا ، شما باید مرکز کنترل و کارگزاران را خاموش کنید ، تنظیمات گزارشگر معیارهای مربوط به کارگزاران را به روز کنید و راه اندازی مجدد کنید.

این پیکربندی با جزئیات بیشتری در آموزش خود تعادل در فعال کردن گزارشگر معیارها برای مرکز کنترل ارائه شده است.

تاخیر مصرف کننده در مرکز کنترل منعکس شده است

با اجرای خود متعادل ، ممکن است تاخیر مصرف کننده را در مرکز کنترل UI برای موضوع سیستم _confluent-telemetry-metrics منعکس کند. شما می توانید این موضوع را نادیده بگیرید ، زیرا نماینده پردازش پیام در این موضوع نیست.

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

تلاش برای حذف کارگزار در هنگام اولیه سازی خود تعادل انجام نمی شود

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

تعادل خود برای جمع آوری معیارهایی برای برنامه های تعادل ، چند دقیقه نیاز دارد. جمع آوری معیارها در حال انجام است. لطفاً بعد از 900 ثانیه دوباره امتحان کنید.

راه حل: راه حل برای این کار این است که 30 دقیقه صبر کنید و دوباره حذف کارگزار را دوباره امتحان کنید.

اگر می خواهید کنترل کننده ای را حذف کنید، عوامل مشابهی در کار هستند، بنابراین باید قبل از اقدام به عملیات حذف مقداری زمان بدهید تا Self-Balancing مقداردهی شود. در این مورد، اگرچه، عملیات "حذف کارگزار" می تواند در مرحله بعدی پس از اینکه کارگزار هدف قبلاً بسته شده است، با شکست مواجه شود. در حالت آفلاین، کارگزار دیگر از مرکز کنترل قابل دسترسی نخواهد بود. اگر این اتفاق افتاد، 30 دقیقه صبر کنید، سپس عملیات حذف بروکر را از خط فرمان دوباره امتحان کنید. هنگامی که Self-Balancing راه اندازی شد و زمان برای جمع آوری معیارها داشت، عملیات باید موفقیت آمیز باشد و طرح تعادل مجدد اجرا می شود.

برای کسب اطلاعات بیشتر در مورد تنظیم اولیه Self-Balancing، به Self-Balancing Initialization مراجعه کنید.

حذف کارگزار به دلیل پارتیشن های آفلاین کامل نمی شود¶

حذف کارگزار همچنین در مواردی که حذف یک کارگزار منجر به داشتن کارگزارهای آنلاین کمتر از تعداد کپی های مورد نیاز در تنظیمات شما می شود، ممکن است با شکست مواجه شود.

وضعیت کارگزار (موجود با kafka-remove-brokers --describe ) تا زمانی که یک یا چند کارگزار آفلاین را راه اندازی مجدد نکنید، به صورت زیر باقی می ماند:

[2020-09-1723:40:53, 743]هشدار[AdminClientشناسه مشتری=adminclient-1]اتصال به گر ه-5(localhost/127. 0. 0. 1:9096)ایجاد نشد. ممکن است کارگزار در دسترس نباشد.(org. apache. kafka. clients.networkClient)دلال1وضعیت حذف: تخصیص مجدد پارتیشن: IN_PROGRESS خاموش شدن کارگزار: کامل

یک راه کوتاه برای عیب یابی این است که بپرسید "چند کارگزار از کار افتاده اند؟"و "چند تکرار/عوامل تکراری باید خوشه پشتیبانی کند؟"

تخصیص مجدد پارتیشن (آخرین مرحله در حذف کارگزار ) در هر موردی که n کارگزار دارید انجام نمی شود و پیکربندی شما به n + 1 یا بیشتر کپی نیاز دارد.

از طرف دیگر، می توانید در نظر بگیرید که برای پشتیبانی از تعداد مورد نیاز نسخه به چند کارگزار آنلاین نیاز دارید. اگر n کارگزار آنلاین دارید، اینها می توانند حداکثر از n کپی پشتیبانی کنند.

راه حل: راه حل این است که کارگزارهای down را مجدداً راه اندازی کنید و شاید پیکربندی کلاستر را به طور کلی تغییر دهید. این ممکن است هم شامل افزودن کارگزاران و هم اصلاح فاکتورهای کپی/تکثیر باشد (نمونه زیر را ببینید).

سناریوهایی که منجر به این مشکل می شوند می توانند ترکیبی از موضوعات کم تکرار شده و موضوعات با کپی های بسیار زیاد برای تعداد کارگزاران آنلاین باشد. داشتن موضوعی با ضریب تکرار 1 لزوماً به خودی خود منجر به مشکل نمی شود.

یک راه سریع برای به دست آوردن یک نمای کلی از کپی های پیکربندی شده در یک خوشه در حال اجرا، استفاده از موضوعات کافکا است -- توصیف در یک موضوع مشخص، یا در کل خوشه (بدون موضوع مشخص). برای موضوعات سیستم، می توانید فاکتورهای تکرار و کپی ها را روی ویژگی های سیستم (که موضوعات سیستم را تولید می کنند) اسکن کنید. آموزش خودبالانسینگ این دستورات، عوامل تکرار/تکرار و تأثیر این تنظیمات را پوشش می دهد.

بسیاری از موضوعات حذف شده باعث ایجاد مشکل در خودتعادل سازی می شود.

حذف بیش از حد بسیاری از موضوعات (و با استنباط، پارتیشن ها) می تواند برای حفظ خوشه ای متوازن اثر معکوس داشته باشد. در آزمون های داخلی، حذف مباحث سیستمی که تقریباً 100 مورد از 500 مبحث کل را تشکیل می دادند، برای قرار دادن خودتعادل در وضعیت کمتر از بهینه کافی بود.

نتیجه آشکار این است که خوشه دائماً در حال تعادل مجدد است.

راه حل: تعداد موضوعات حذف شده را کاهش دهید. گزینه های پیکربندی مربوطه برای تغییر این تنظیمات عبارتند از: ref: sbc-config-exclude-topic-names و confluent. balancer. exclude. topic. prefixes.

مطالعه پیشنهادی¶

• پست وبلاگ: بازگرداندن تعادل به خوشه: خوشه های خود متعادل کننده در پلتفرم همخوان
• پست وبلاگ: معرفی Confluent Platform 6. 0
• خود متعادل کننده در مقابل متعادل کننده داده خودکار
• آموزش خود تعادلی
• دمو شروع سریع (Docker)
• تنظیمات و دستورات پیکربندی
• با Self-Balancing Cluster در تنظیمات خوشه در راهنمای کاربر Control Center کار کنید
• پروکسی REST
• مرجع API پروکسی REST متجانس

بازخورد

Confluent Cloud یک سرویس Apache Kafka با مدیریت کامل است که در هر سه ابر اصلی موجود است. امروز آن را رایگان امتحان کنید.

حق چاپ © Confluent, Inc. 2014-. آپاچی، آپاچی کافکا، کافکا و نام های پروژه منبع باز مرتبط علائم تجاری بنیاد نرم افزار آپاچی هستند.