🥇تعیین اندازه مناسب برای خوشه کافکا در Kubernetes

توجه داشته باشید. ترجمه: در این مقاله، Banzai Cloud مثالی از نحوه استفاده از ابزارهای سفارشی خود برای سهولت استفاده از کافکا در Kubernetes به اشتراک می گذارد. دستورالعمل های زیر نشان می دهد که چگونه می توانید اندازه بهینه زیرساخت خود را تعیین کنید و خود کافکا را برای دستیابی به توان عملیاتی مورد نیاز پیکربندی کنید.

آپاچی کافکا یک پلتفرم استریم توزیع شده برای ایجاد سیستم های پخش بلادرنگ قابل اعتماد، مقیاس پذیر و با کارایی بالا است. قابلیت های چشمگیر آن را می توان با استفاده از Kubernetes گسترش داد. برای این ما توسعه داده ایم اپراتور کافکا منبع باز و ابزاری به نام سوپر تیوب ها. آنها به شما امکان می دهند کافکا را روی Kubernetes اجرا کنید و از ویژگی های مختلف آن استفاده کنید، مانند تنظیم دقیق پیکربندی کارگزار، مقیاس بندی مبتنی بر متریک با تعادل مجدد، آگاهی از رک، "نرم" (برازنده) ارائه به روز رسانی ها و غیره

Supertubes را در کلاستر خود امتحان کنید:
curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>
یا تماس بگیرید مستندات. همچنین می توانید در مورد برخی از قابلیت های کافکا که کار با آن با استفاده از سوپر تیوب و اپراتور کافکا به صورت خودکار انجام می شود، مطالعه کنید. قبلاً در وبلاگ در مورد آنها نوشته ایم:

وای نه! یک اپراتور کافکا دیگر برای Kubernetes;

کافکا را بر اساس معیارهای پرومتئوس رصد و اجرا کنید;

آگاهی قفسه کافکا در Kubernetes;

اجرای آپاچی کافکا بر روی ایستیو - معیار;

کاربر احراز هویت و دسترسی به خوشه های کنترل شده با اپراتور کافکا;

ارتقاء نورد کافکا و پیکربندی پویا در Kubernetes;

فیلتر پروتکل فرستاده برای کافکا، مشبک شده.

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

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

از نظر تئوری، ما همچنین می‌توانیم تعداد کارگزاران مورد نیاز برای رسیدگی به یک بار معین را تخمین بزنیم. با این حال، در عمل گزینه های پیکربندی زیادی در سطوح مختلف وجود دارد که ارزیابی عملکرد بالقوه یک پیکربندی خاص بسیار دشوار (اگر نه غیرممکن) است. به عبارت دیگر، برنامه ریزی یک پیکربندی بر اساس برخی عملکردهای داده شده بسیار دشوار است.

برای کاربران Supertubes، ما معمولاً رویکرد زیر را در پیش می گیریم: با برخی از تنظیمات (زیرساخت + تنظیمات) شروع می کنیم، سپس عملکرد آن را اندازه گیری می کنیم، تنظیمات کارگزار را تنظیم می کنیم و دوباره این فرآیند را تکرار می کنیم. این تا زمانی اتفاق می افتد که کندترین جزء زیرساخت به طور کامل مورد استفاده قرار گیرد.

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

این مقاله در مورد مراحلی که برای استفاده حداکثری از کندترین اجزا در پیکربندی های اولیه و اندازه گیری توان عملیاتی یک خوشه کافکا انجام می دهیم صحبت خواهد کرد. یک پیکربندی بسیار انعطاف پذیر به حداقل سه کارگزار در حال اجرا نیاز دارد (min.insync.replicas=3، در سه منطقه دسترسی مختلف توزیع شده است. برای پیکربندی، مقیاس و نظارت بر زیرساخت Kubernetes، ما از پلت فرم مدیریت کانتینر خود برای ابرهای ترکیبی استفاده می کنیم - خط لوله. این نرم افزار داخلی (متال لخت، VMware) و پنج نوع ابر (Alibaba، AWS، Azure، Google، Oracle) و همچنین هر ترکیبی از آنها را پشتیبانی می کند.

افکاری در مورد زیرساخت و پیکربندی خوشه کافکا

برای مثال های زیر، AWS را به عنوان ارائه دهنده ابر و EKS را به عنوان توزیع Kubernetes انتخاب کردیم. پیکربندی مشابهی را می توان با استفاده از آن پیاده سازی کرد P.K.E. - توزیع Kubernetes از Banzai Cloud، دارای گواهی CNCF.

دیسک

آمازون انواع مختلفی را ارائه می دهد انواع حجم EBS... در قلب gp2 и io1 با این حال، درایوهای SSD برای اطمینان از توان بالا وجود دارد gp2 اعتبارات انباشته را مصرف می کند (اعتبار ورودی/خروجی)، بنابراین ما نوع را ترجیح دادیم io1، که توان عملیاتی بالا را ارائه می دهد.

انواع نمونه

عملکرد کافکا به شدت به کش صفحه سیستم عامل وابسته است، بنابراین ما به نمونه هایی با حافظه کافی برای کارگزاران (JVM) و کش صفحه نیاز داریم. نمونه، مثال c5.2xlarge - شروع خوبی است، زیرا دارای 16 گیگابایت حافظه و برای کار با EBS بهینه شده است. نقطه ضعف آن این است که تنها قادر است حداکثر عملکرد را برای حداکثر 30 دقیقه در هر 24 ساعت ارائه دهد. اگر حجم کاری شما به اوج عملکرد در مدت زمان طولانی تری نیاز دارد، ممکن است بخواهید انواع دیگر را در نظر بگیرید. این دقیقاً همان کاری است که ما انجام دادیم c5.4xlarge. حداکثر توان عملیاتی را در اختیار شما قرار می دهد 593,75 مگابیت بر ثانیه. حداکثر توان خروجی یک حجم EBS io1 بالاتر از نمونه c5.4xlarge، بنابراین کندترین عنصر زیرساخت احتمالاً خروجی ورودی/خروجی این نوع نمونه است (که آزمایش‌های بار ما نیز باید تأیید کنند).

شبکه

توان عملیاتی شبکه باید در مقایسه با عملکرد نمونه VM و دیسک به اندازه کافی بزرگ باشد، در غیر این صورت شبکه به یک گلوگاه تبدیل می شود. در مورد ما، رابط شبکه c5.4xlarge سرعت حداکثر 10 گیگابیت بر ثانیه را پشتیبانی می کند که به طور قابل توجهی بالاتر از توان I/O یک نمونه VM است.

استقرار کارگزار

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

نسخه جاوا

انتخاب منطقی جاوا 11 است زیرا با Docker سازگار است به این معنا که JVM به درستی پردازنده ها و حافظه موجود در ظرفی را که کارگزار در آن در حال اجراست تعیین می کند. با دانستن اینکه محدودیت های CPU مهم هستند، JVM به صورت داخلی و شفاف تعداد رشته های GC و رشته های JIT را تعیین می کند. ما از تصویر کافکا استفاده کردیم banzaicloud/kafka:2.13-2.4.0که شامل کافکا نسخه 2.4.0 (Scala 2.13) در جاوا 11 است.

اگر می‌خواهید درباره جاوا/JVM در Kubernetes اطلاعات بیشتری کسب کنید، پست‌های زیر را بررسی کنید:

چرا برنامه جاوا من OOMKilled است;

نحوه اندازه گیری صحیح کانتینرها برای برنامه های جاوا 10.

تنظیمات حافظه کارگزار

دو جنبه کلیدی برای پیکربندی حافظه کارگزار وجود دارد: تنظیمات برای JVM و برای Kubernetes pod. محدودیت حافظه تنظیم شده برای یک پاد باید بیشتر از حداکثر اندازه پشته باشد تا JVM فضایی برای فرافضای جاوا داشته باشد که در حافظه خودش قرار دارد و برای کش صفحه سیستم عامل که کافکا فعالانه از آن استفاده می کند. در آزمایش‌های خود، بروکرهای کافکا را با پارامترها راه‌اندازی کردیم -Xmx4G -Xms2Gو محدودیت حافظه برای پاد بود 10 Gi. لطفاً توجه داشته باشید که تنظیمات حافظه برای JVM را می توان به طور خودکار با استفاده از آن به دست آورد -XX:MaxRAMPercentage и -X:MinRAMPercentage، بر اساس محدودیت حافظه برای غلاف.

تنظیمات پردازنده کارگزار

به طور کلی، شما می توانید با افزایش موازی با افزایش تعداد نخ های استفاده شده توسط کافکا، عملکرد را بهبود بخشید. هرچه پردازنده های بیشتری برای کافکا موجود باشد، بهتر است. در آزمایش خود، با محدودیت 6 پردازنده شروع کردیم و به تدریج (از طریق تکرار) تعداد آنها را به 15 رساندیم. علاوه بر این، ما تنظیم کردیم. num.network.threads=12 در تنظیمات کارگزار برای افزایش تعداد رشته هایی که داده ها را از شبکه دریافت می کنند و ارسال می کنند. بلافاصله متوجه شدند که کارگزاران فالوور نمی توانند نسخه های مشابه را به سرعت کافی دریافت کنند، آنها را مطرح کردند. num.replica.fetchers به 4 تا سرعت تکرار پیام های رهبران توسط کارگزاران فالوور افزایش یابد.

ابزار تولید بار

باید اطمینان حاصل کنید که مولد بار انتخابی قبل از اینکه خوشه کافکا (که در حال محک زدن است) به حداکثر بار خود برسد، ظرفیتش تمام نشود. به عبارت دیگر، ارزیابی اولیه از قابلیت های ابزار تولید بار و همچنین انتخاب انواع نمونه برای آن با تعداد کافی پردازنده و حافظه ضروری است. در این حالت، ابزار ما بار بیشتری نسبت به خوشه کافکا تولید خواهد کرد. پس از آزمایش‌های فراوان، روی سه نسخه قرار گرفتیم c5.4xlargeکه هر کدام یک ژنراتور در حال کار بودند.

محک زدن

اندازه گیری عملکرد یک فرآیند تکراری است که شامل مراحل زیر است:

راه اندازی زیرساخت (خوشه EKS، خوشه کافکا، ابزار تولید بار، و همچنین Prometheus و Grafana)؛
ایجاد بار برای یک دوره معین برای فیلتر کردن انحرافات تصادفی در شاخص های عملکرد جمع آوری شده؛
تنظیم زیرساخت و پیکربندی کارگزار بر اساس شاخص های عملکرد مشاهده شده؛
تکرار فرآیند تا رسیدن به سطح مورد نیاز خوشه کافکا. در عین حال، باید به طور مداوم قابل تکرار باشد و حداقل تغییرات در توان را نشان دهد.

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

ابزارهای

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

خط لوله ابر Banzai برای سازماندهی یک خوشه EKS از آمازون c تیتان فرزند پاپتوس (برای جمع آوری معیارهای کافکا و زیرساخت) و گرافانا (برای تجسم این معیارها). بهره بردیم یکپارچه в خط لوله خدماتی که نظارت فدرال، جمع آوری گزارش متمرکز، اسکن آسیب پذیری، بازیابی فاجعه، امنیت در سطح سازمانی و بسیاری موارد دیگر را ارائه می دهند.
سانگرنل - ابزاری برای آزمایش بار یک خوشه کافکا.
داشبوردهای گرافانا برای تجسم معیارها و زیرساخت های کافکا: Kubernetes Kafka, صادر کننده گره.
Supertubes CLI برای ساده ترین راه برای راه اندازی یک خوشه کافکا در Kubernetes. Zookeeper، اپراتور Kafka، Envoy و بسیاری از مؤلفه‌های دیگر برای اجرای یک خوشه کافکای آماده برای تولید در Kubernetes نصب و به درستی پیکربندی شده‌اند.
- برای نصب سوپر تیوب CLI از دستورالعمل های ارائه شده استفاده کنید اینجا.

خوشه EKS

یک خوشه EKS با گره های کارگر اختصاصی آماده کنید c5.4xlarge در مناطق مختلف در دسترس برای غلاف با کارگزاران کافکا، و همچنین گره های اختصاصی برای مولد بار و زیرساخت نظارت.

banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.json

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

اجزای سیستم کافکا

اجزای سیستم کافکا (Zookeeper، kafka-operator) را در EKS با استفاده از سوپر تیوب CLI نصب کنید:

supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

خوشه کافکا

به طور پیش فرض، EKS از نوع حجم های EBS استفاده می کند gp2، بنابراین باید یک کلاس ذخیره سازی جداگانه بر اساس حجم ایجاد کنید io1 برای خوشه کافکا:

kubectl create -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  iopsPerGB: "50"
  fsType: ext4
volumeBindingMode: WaitForFirstConsumer
EOF

پارامتر را برای کارگزاران تنظیم کنید min.insync.replicas=3 و غلاف های کارگزار را بر روی گره ها در سه منطقه مختلف در دسترس مستقر کنید:

supertubes cluster create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/kafka_202001_3brokers.yaml --wait --timeout 600

موضوعات

ما سه نمونه مولد بار را به صورت موازی اجرا کردیم. هر کدام از آنها برای موضوع خود می نویسند، یعنی در کل به سه موضوع نیاز داریم:

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest1
spec:
  name: perftest1
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
    name: perftest2
spec:
  name: perftest2
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest3
spec:
  name: perftest3
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

برای هر موضوع، ضریب تکرار 3 است - حداقل مقدار توصیه شده برای سیستم های تولید بسیار در دسترس.

ابزار تولید بار

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

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: loadtest
  name: perf-load1
  namespace: kafka
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: loadtest
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: loadtest
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nodepool.banzaicloud.io/name
                operator: In
                values:
                - loadgen
      containers:
      - args:
        - -brokers=kafka-0:29092,kafka-1:29092,kafka-2:29092,kafka-3:29092
        - -topic=perftest1
        - -required-acks=all
        - -message-size=512
        - -workers=20
        image: banzaicloud/perfload:0.1.0-blog
        imagePullPolicy: Always
        name: sangrenel
        resources:
          limits:
            cpu: 2
            memory: 1Gi
          requests:
            cpu: 2
            memory: 1Gi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

چند نکته قابل توجه:

مولد بار پیام هایی به طول 512 بایت تولید می کند و آنها را در دسته های 500 پیام برای کافکا منتشر می کند.
استفاده از استدلال -required-acks=all این انتشار زمانی موفقیت آمیز تلقی می شود که همه کپی های همگام شده پیام توسط کارگزاران کافکا دریافت و تایید شود. این بدان معنی است که در معیار ما نه تنها سرعت دریافت پیام توسط رهبران، بلکه پیروان آنها را نیز در تکرار پیام اندازه گیری کردیم. هدف از این تست ارزیابی سرعت مطالعه مصرف کننده نیست (مصرف کنندگان) اخیراً پیام‌هایی دریافت کرده‌اند که هنوز در حافظه پنهان صفحه سیستم عامل باقی می‌مانند و مقایسه آن با سرعت خواندن پیام‌های ذخیره شده روی دیسک.
ژنراتور بار 20 کارگر را به صورت موازی کار می کند (-workers=20). هر کارگر شامل 5 تولیدکننده است که در ارتباط کارگر با خوشه کافکا سهیم هستند. در نتیجه هر مولد 100 تولید کننده دارد و همه آنها پیام هایی را به خوشه کافکا ارسال می کنند.

نظارت بر سلامت خوشه

در طول آزمایش بار خوشه کافکا، ما همچنین سلامت آن را کنترل کردیم تا مطمئن شویم که هیچ راه‌اندازی مجدد غلاف، هیچ کپی خارج از همگام‌سازی و حداکثر توان با حداقل نوسانات وجود ندارد:

مولد بار آمار استانداردی را در مورد تعداد پیام های منتشر شده و میزان خطا می نویسد. میزان خطا باید ثابت بماند 0,00%.
کنترل کروز، که توسط kafka-operator مستقر شده است، داشبوردی را ارائه می دهد که در آن می توانیم وضعیت خوشه را نیز نظارت کنیم. برای مشاهده این پنل:
```
supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file>
```
سطح ISR (تعداد کپی های "در همگام") جمع شدن و انبساط برابر با 0 است.

نتایج اندازه گیری

3 کارگزار، اندازه پیام - 512 بایت

با توزیع یکنواخت پارتیشن ها در بین سه کارگزار، ما توانستیم به عملکردی دست یابیم ~ 500 مگابیت بر ثانیه (تقریباً 990 هزار پیام در ثانیه):

مصرف حافظه ماشین مجازی JVM از 2 گیگابایت تجاوز نکرد:

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

از داده‌های مربوط به استفاده از حافظه توسط گره‌ها، چنین بر می‌آید که بافر و کش سیستم 10-15 گیگابایت طول کشیده است:

3 کارگزار، اندازه پیام - 100 بایت

با کاهش اندازه پیام، توان عملیاتی تقریباً 15-20٪ کاهش می یابد: زمان صرف شده برای پردازش هر پیام بر آن تأثیر می گذارد. علاوه بر این، بار پردازنده تقریبا دو برابر شده است.

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

4 کارگزار، اندازه پیام - 512 بایت

شما به راحتی می توانید با اضافه کردن کارگزاران جدید و حفظ تعادل پارتیشن ها، عملکرد یک خوشه کافکا را افزایش دهید (این کار باعث می شود که بار به طور مساوی بین کارگزاران توزیع شود). در مورد ما، پس از افزودن یک کارگزار، توان عملیاتی خوشه به افزایش یافت ~580 Mb/s (~1,1 میلیون پیام در ثانیه). رشد کمتر از حد انتظار بود: این عمدتاً با عدم تعادل پارتیشن ها توضیح داده می شود (همه کارگزاران در اوج توانایی های خود کار نمی کنند).

مصرف حافظه دستگاه JVM زیر 2 گیگابایت باقی ماند:

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

یافته ها

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

ما Supertubes را برای استقرار سریع و آسان یک خوشه، پیکربندی آن، افزودن/حذف بروکرها و موضوعات، پاسخ دادن به هشدارها و اطمینان از عملکرد صحیح کافکا در Kubernetes طراحی کردیم. هدف ما این است که به شما کمک کنیم روی کار اصلی ("تولید" و "مصرف" پیام های کافکا) تمرکز کنید و تمام کار سخت را به Supertubes و اپراتور کافکا بسپارید.

اگر به فن‌آوری‌های Banzai Cloud و پروژه‌های منبع باز علاقه دارید، در این شرکت مشترک شوید GitHub, لینک یا توییتر.

PS از مترجم

در وبلاگ ما نیز بخوانید:

منبع: www.habr.com

اندازه مناسب برای خوشه کافکا در Kubernetes را تعیین کنید

افکاری در مورد زیرساخت و پیکربندی خوشه کافکا

دیسک

انواع نمونه

شبکه

استقرار کارگزار

نسخه جاوا

تنظیمات حافظه کارگزار

تنظیمات پردازنده کارگزار

ابزار تولید بار

محک زدن

ابزارهای

خوشه EKS

اجزای سیستم کافکا

خوشه کافکا

موضوعات

ابزار تولید بار

نظارت بر سلامت خوشه

نتایج اندازه گیری

3 کارگزار، اندازه پیام - 512 بایت

3 کارگزار، اندازه پیام - 100 بایت

4 کارگزار، اندازه پیام - 512 بایت

یافته ها

PS از مترجم

اضافه کردن نظر انصراف از پاسخ