क्षमता, Upgrades और Managed Services

योजना बनाएँ, फिर गुंजाइश रखें

Storage (प्रतिदिन डेटा × retention × replication factor, साथ में लगभग 20-30% गुंजाइश), network (अंदर आते producers + replication + बाहर जाते consumers) और प्रति broker partitions का अनुमान लगाएँ। Upgrade rolling restarts से, एक बार में एक broker, release notes और upgrade क्रम का पालन करते हुए करें, और पहले staging में परखें। तय करें कि cluster कौन चलाएगा: self-managed (पूरा नियंत्रण, upgrades, सुरक्षा और on-call के लिए विशेषज्ञता चाहिए) या managed service (Confluent Cloud, Amazon MSK, Kafka के लिए Azure Event Hubs, Redpanda Cloud और अन्य) जो कुछ नियंत्रण और लागत के बदले कम संचालन-काम देती है। Brokers को availability zones में फैलाएँ और rack awareness चालू करें ताकि replicas अलग zones में रहें।

क्षमता worksheet

अंक उदाहरण हैं। मुद्दा हार्डवेयर ख़रीदने या plan चुनने से पहले गणना करना है।

Ingress                 20 MB/s average, 60 MB/s peak
Replication factor      3  -> inter-broker traffic ~ 2 x ingress
Consumers               3 groups -> egress ~ 3 x ingress
Retention               7 days -> 20 MB/s x 86,400 s x 7 x 3 replicas ~ 36 TB raw, +25% headroom
Brokers                 6 across 3 AZs (rack awareness on)
Partitions              ~1,000-2,000 per broker is a comfortable range for most clusters

त्वरित जाँच: Brokers को एक बार में एक क्यों upgrade करें?

• ताकि पर्याप्त in-sync replicas उपलब्ध रहें और writes चलते रहें
• Brokers एक साथ restart नहीं हो सकते
• इससे upgrades मुफ़्त हो जाते हैं
• सिर्फ़ managed services के लिए