Nodyn. traws.: Yn yr erthygl hon, mae Banzai Cloud yn rhannu enghraifft o sut y gellir defnyddio ei offer arfer i wneud Kafka yn haws i'w defnyddio o fewn Kubernetes. Mae'r cyfarwyddiadau canlynol yn dangos sut y gallwch chi bennu maint optimaidd eich seilwaith a ffurfweddu Kafka ei hun i gyflawni'r trwybwn gofynnol.
Mae Apache Kafka yn blatfform ffrydio dosbarthedig ar gyfer creu systemau ffrydio amser real dibynadwy, graddadwy a pherfformiad uchel. Gellir ymestyn ei alluoedd trawiadol gan ddefnyddio Kubernetes. Ar gyfer hyn rydym wedi datblygu ac offeryn o'r enw . Maent yn caniatáu ichi redeg Kafka ar Kubernetes a defnyddio ei nodweddion amrywiol, megis mireinio cyfluniad y brocer, graddio'n seiliedig ar fetrig ac ail-gydbwyso, ymwybyddiaeth rac, "meddal" (gosgeiddig) cyflwyno diweddariadau, ac ati.
Rhowch gynnig ar Supertubes yn eich clwstwr:
curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>Neu cysylltwch . Gallwch hefyd ddarllen am rai o alluoedd Kafka, y mae'r gwaith yn ei wneud yn awtomataidd gan ddefnyddio Supertubes a gweithredwr Kafka. Rydyn ni eisoes wedi ysgrifennu amdanyn nhw ar y blog:
- ;
- ;
- ;
- ;
- ;
- ;
- .
Pan fyddwch chi'n penderfynu lleoli clwstwr Kafka ar Kubernetes, mae'n debygol y byddwch chi'n wynebu'r her o bennu maint optimaidd y seilwaith sylfaenol a'r angen i fireinio'ch ffurfwedd Kafka i fodloni gofynion trwybwn. Mae perfformiad uchaf pob brocer yn cael ei bennu gan berfformiad y cydrannau seilwaith sylfaenol, megis cof, prosesydd, cyflymder disg, lled band rhwydwaith, ac ati.
Yn ddelfrydol, dylai cyfluniad y brocer fod yn gyfryw fel bod yr holl elfennau seilwaith yn cael eu defnyddio i'w galluoedd mwyaf. Fodd bynnag, mewn bywyd go iawn mae'r gosodiad hwn yn eithaf cymhleth. Mae'n fwy tebygol y bydd defnyddwyr yn ffurfweddu broceriaid i wneud y defnydd gorau o un neu ddau o gydrannau (disg, cof, neu brosesydd). Yn gyffredinol, mae brocer yn dangos y perfformiad mwyaf posibl pan fydd ei ffurfweddiad yn caniatáu i'r gydran arafaf gael ei defnyddio i'r eithaf. Fel hyn gallwn gael syniad bras o'r llwyth y gall un brocer ei drin.
Yn ddamcaniaethol, gallwn hefyd amcangyfrif nifer y broceriaid sydd eu hangen i drin llwyth penodol. Fodd bynnag, yn ymarferol mae cymaint o opsiynau cyfluniad ar wahanol lefelau fel ei bod yn anodd iawn (os nad yn amhosibl) gwerthuso perfformiad posibl cyfluniad penodol. Mewn geiriau eraill, mae'n anodd iawn cynllunio cyfluniad yn seiliedig ar rai perfformiad penodol.
Ar gyfer defnyddwyr Supertubes, rydym fel arfer yn cymryd y dull canlynol: rydym yn dechrau gyda rhywfaint o gyfluniad (isadeiledd + gosodiadau), yna mesur ei berfformiad, addasu gosodiadau'r brocer ac ailadrodd y broses eto. Mae hyn yn digwydd nes bod elfen arafaf y seilwaith yn cael ei defnyddio'n llawn.
Yn y modd hwn, rydyn ni'n cael syniad cliriach o faint o froceriaid sydd eu hangen ar glwstwr i drin llwyth penodol (mae nifer y broceriaid hefyd yn dibynnu ar ffactorau eraill, megis y nifer lleiaf o atgynyrchiadau neges i sicrhau gwydnwch, nifer y rhaniad arweinwyr, ac ati). Yn ogystal, rydym yn cael mewnwelediad i ba gydrannau seilwaith sydd angen eu graddio'n fertigol.
Bydd yr erthygl hon yn sôn am y camau a gymerwn i gael y gorau o'r cydrannau arafaf mewn ffurfweddiadau cychwynnol a mesur trwygyrch clwstwr Kafka. Mae cyfluniad hynod wydn yn gofyn am o leiaf dri brocer rhedeg (min.insync.replicas=3), wedi'i ddosbarthu ar draws tri pharth hygyrchedd gwahanol. I ffurfweddu, graddio a monitro seilwaith Kubernetes, rydym yn defnyddio ein platfform rheoli cynwysyddion ein hunain ar gyfer cymylau hybrid - . Mae'n cefnogi ar y safle (metel noeth, VMware) a phum math o gymylau (Alibaba, AWS, Azure, Google, Oracle), yn ogystal ag unrhyw gyfuniad ohonynt.
Syniadau am seilwaith a chyfluniad clwstwr Kafka
Ar gyfer yr enghreifftiau isod, gwnaethom ddewis AWS fel darparwr y cwmwl ac EKS fel dosbarthiad Kubernetes. Gellir gweithredu cyfluniad tebyg gan ddefnyddio - Dosbarthiad Kubernetes o Banzai Cloud, wedi'i ardystio gan CNCF.
Gyrru
Mae Amazon yn cynnig amrywiol . Yn y craidd gp2 и io1 mae gyriannau SSD, fodd bynnag, i sicrhau trwybwn uchel gp2 yn defnyddio credydau cronedig (credydau I/O), felly roedd yn well gennym y math io1, sy'n cynnig trwybwn uchel cyson.
Mathau o achosion
Mae perfformiad Kafka yn ddibynnol iawn ar storfa tudalen y system weithredu, felly mae angen achosion gyda digon o gof ar gyfer y broceriaid (JVM) a storfa'r dudalen. Er enghraifft c5.2xlarge - dechrau da, gan fod ganddo 16 GB o gof a . Ei anfantais yw ei fod ond yn gallu darparu perfformiad uchaf am ddim mwy na 30 munud bob 24 awr. Os yw eich llwyth gwaith yn gofyn am berfformiad brig dros gyfnod hwy o amser, efallai y byddwch am ystyried mathau eraill o enghreifftiau. Dyna'n union a wnaethom, gan stopio c5.4xlarge. Mae'n darparu'r trwybwn mwyaf i mewn 593,75 Mbps. Uchafswm trwybwn cyfaint EBS io1 uwch na'r enghraifft c5.4xlarge, felly mae'n debyg mai'r elfen arafaf o'r seilwaith yw'r trwybwn I/O o'r math hwn (y dylai ein profion llwyth hefyd ei gadarnhau).
Rhwydwaith
Rhaid i'r trwybwn rhwydwaith fod yn ddigon mawr o'i gymharu â pherfformiad yr enghraifft VM a'r ddisg, fel arall mae'r rhwydwaith yn dod yn dagfa. Yn ein hachos ni, y rhyngwyneb rhwydwaith c5.4xlarge yn cefnogi cyflymderau hyd at 10 Gb/s, sy'n sylweddol uwch na mewnbwn I/O enghraifft VM.
Defnydd Brocer
Dylid defnyddio broceriaid (wedi'u hamserlennu yn Kubernetes) i nodau pwrpasol er mwyn osgoi cystadlu â phrosesau eraill ar gyfer adnoddau CPU, cof, rhwydwaith a disg.
Fersiwn Java
Y dewis rhesymegol yw Java 11 oherwydd ei fod yn gydnaws â Docker yn yr ystyr bod y JVM yn pennu'n gywir y proseswyr a'r cof sydd ar gael i'r cynhwysydd y mae'r brocer yn rhedeg ynddo. Gan wybod bod terfynau CPU yn bwysig, mae'r JVM yn fewnol ac yn dryloyw yn gosod nifer yr edafedd GC ac edafedd JIT. Fe wnaethon ni ddefnyddio'r ddelwedd Kafka banzaicloud/kafka:2.13-2.4.0, sy'n cynnwys fersiwn Kafka 2.4.0 (Scala 2.13) ar Java 11.
Os hoffech chi ddysgu mwy am Java / JVM ar Kubernetes, edrychwch ar ein swyddi canlynol:
- ;
- .
Gosodiadau cof brocer
Mae dwy agwedd allweddol ar ffurfweddu cof brocer: gosodiadau ar gyfer y JVM ac ar gyfer y pod Kubernetes. Rhaid i'r terfyn cof a osodwyd ar gyfer pod fod yn fwy na'r maint pentwr uchaf fel bod gan y JVM le ar gyfer y metaspace Java sy'n byw yn ei gof ei hun ac ar gyfer storfa tudalen y system weithredu y mae Kafka yn ei defnyddio'n weithredol. Yn ein profion fe wnaethom lansio broceriaid Kafka gyda pharamedrau -Xmx4G -Xms2G, a therfyn cof am y pod oedd 10 Gi. Sylwch y gellir cael gosodiadau cof ar gyfer y JVM yn awtomatig gan ddefnyddio -XX:MaxRAMPercentage и -X:MinRAMPercentage, yn seiliedig ar y terfyn cof ar gyfer y pod.
Gosodiadau prosesydd brocer
A siarad yn gyffredinol, gallwch wella perfformiad trwy gynyddu paraleliaeth trwy gynyddu nifer yr edafedd a ddefnyddir gan Kafka. Gorau po fwyaf o broseswyr sydd ar gael ar gyfer Kafka. Yn ein prawf, fe wnaethom ddechrau gyda therfyn o 6 prosesydd ac yn raddol (trwy iteriadau) codi eu nifer i 15. Yn ogystal, fe wnaethom osod num.network.threads=12 yn y gosodiadau brocer i gynyddu nifer yr edafedd sy'n derbyn data o'r rhwydwaith a'i anfon. Gan ddarganfod ar unwaith na allai'r broceriaid dilynwyr dderbyn replicas yn ddigon cyflym, codasant num.replica.fetchers i 4 i gynyddu'r cyflymder y mae broceriaid dilynwyr yn ailadrodd negeseuon gan arweinwyr.
Offeryn Cynhyrchu Llwyth
Dylech sicrhau nad yw'r generadur llwyth a ddewiswyd yn rhedeg allan o gapasiti cyn i'r clwstwr Kafka (sy'n cael ei feincnodi) gyrraedd ei uchafswm llwyth. Mewn geiriau eraill, mae angen cynnal asesiad rhagarweiniol o alluoedd yr offeryn cynhyrchu llwyth, a hefyd dewis mathau o enghreifftiau ar ei gyfer gyda nifer digonol o broseswyr a chof. Yn yr achos hwn, bydd ein hofferyn yn cynhyrchu mwy o lwyth nag y gall clwstwr Kafka ei drin. Ar ôl llawer o arbrofion, fe wnaethom setlo ar dri chopi c5.4xlarge, ac roedd gan bob un ohonynt eneradur yn rhedeg.
Meincnodi
Mae mesur perfformiad yn broses ailadroddol sy'n cynnwys y camau canlynol:
- sefydlu seilwaith (clwstwr EKS, clwstwr Kafka, offeryn cynhyrchu llwyth, yn ogystal â Prometheus a Grafana);
- cynhyrchu llwyth am gyfnod penodol i hidlo gwyriadau ar hap yn y dangosyddion perfformiad a gasglwyd;
- addasu seilwaith a chyfluniad y brocer yn seiliedig ar ddangosyddion perfformiad a arsylwyd;
- ailadrodd y broses nes cyrraedd y lefel ofynnol o drwybwn clwstwr Kafka. Ar yr un pryd, rhaid iddo fod yn gyson atgenhedladwy a rhaid iddo ddangos amrywiadau bach iawn yn y trwybwn.
Mae'r adran nesaf yn disgrifio'r camau a gyflawnwyd yn ystod y broses feincnodi clwstwr prawf.
Offer
Defnyddiwyd yr offer canlynol i ddefnyddio cyfluniad gwaelodlin yn gyflym, cynhyrchu llwythi, a mesur perfformiad:
- am drefnu clwstwr EKS o Amazon c (i gasglu Kafka a metrigau seilwaith) a (i ddelweddu'r metrigau hyn). Fe wnaethon ni fanteisio integredig в gwasanaethau sy'n darparu monitro ffederal, casglu logiau canolog, sganio bregusrwydd, adfer ar ôl trychineb, diogelwch gradd menter a llawer mwy.
- - offeryn ar gyfer profi llwyth clwstwr Kafka.
- Dangosfyrddau Grafana ar gyfer delweddu metrigau a seilwaith Kafka: , .
- Supertubes CLI am y ffordd hawsaf o sefydlu clwstwr Kafka ar Kubernetes. Mae Zookeeper, gweithredwr Kafka, Envoy a llawer o gydrannau eraill wedi'u gosod a'u ffurfweddu'n gywir i redeg clwstwr Kafka sy'n barod ar gyfer cynhyrchu ar Kubernetes.
- Ar gyfer gosod supertubes CLI defnyddio'r cyfarwyddiadau a ddarperir .
Clwstwr EKS
Paratoi clwstwr EKS gyda nodau gweithwyr penodedig c5.4xlarge mewn gwahanol barthau argaeledd ar gyfer codennau gyda broceriaid Kafka, yn ogystal â nodau pwrpasol ar gyfer y generadur llwyth a'r seilwaith monitro.
banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.jsonUnwaith y bydd y clwstwr EKS yn weithredol, galluogwch ei integredig — bydd hi'n lleoli Prometheus a Grafana yn glwstwr.
Cydrannau system Kafka
Gosod cydrannau system Kafka (Zookeeper, kafka-operator) yn EKS gan ddefnyddio supertubes CLI:
supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>Clwstwr Kafka
Yn ddiofyn, mae EKS yn defnyddio cyfeintiau EBS o fath gp2, felly mae angen i chi greu dosbarth storio ar wahân yn seiliedig ar gyfeintiau io1 ar gyfer clwstwr Kafka:
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
Gosodwch y paramedr ar gyfer broceriaid min.insync.replicas=3 a defnyddio codennau brocer ar nodau mewn tri pharth argaeledd gwahanol:
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 600Pynciau
Fe wnaethom redeg tri achos generadur llwyth ochr yn ochr. Mae pob un ohonynt yn ysgrifennu at eu pwnc eu hunain, hynny yw, mae angen tri phwnc i gyd:
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
EOFAr gyfer pob pwnc, y ffactor atgynhyrchu yw 3 - y gwerth lleiaf a argymhellir ar gyfer systemau cynhyrchu sydd ar gael yn fawr.
Offeryn Cynhyrchu Llwyth
Fe wnaethom lansio tri chopi o'r generadur llwyth (ysgrifennodd pob un mewn pwnc ar wahân). Ar gyfer codennau generadur llwyth, mae angen i chi osod affinedd nodau fel eu bod wedi'u hamserlennu ar y nodau a neilltuwyd ar eu cyfer yn unig:
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: 30Ychydig o bwyntiau i'w nodi:
- Mae'r generadur llwyth yn cynhyrchu negeseuon o 512 beit o hyd ac yn eu cyhoeddi i Kafka mewn sypiau o 500 o negeseuon.
- Defnyddio dadl
-required-acks=allYstyrir bod y cyhoeddiad yn llwyddiannus pan fydd broceriaid Kafka yn derbyn ac yn cadarnhau pob atgynhyrchiad cydamserol o'r neges. Mae hyn yn golygu ein bod yn y meincnod nid yn unig wedi mesur cyflymder yr arweinwyr yn derbyn negeseuon, ond hefyd eu dilynwyr yn atgynhyrchu negeseuon. Nid pwrpas y prawf hwn yw gwerthuso cyflymder darllen defnyddwyr (defnyddwyr) negeseuon a dderbyniwyd yn ddiweddar sy'n dal i aros yn y storfa tudalen OS, a'i gymharu â chyflymder darllen negeseuon sydd wedi'u storio ar ddisg. - Mae'r generadur llwyth yn rhedeg 20 o weithwyr ochr yn ochr (
-workers=20). Mae pob gweithiwr yn cynnwys 5 cynhyrchydd sy'n rhannu cysylltiad y gweithiwr â chlwstwr Kafka. O ganlyniad, mae gan bob generadur 100 o gynhyrchwyr, ac maent i gyd yn anfon negeseuon i glwstwr Kafka.
Monitro iechyd y clwstwr
Yn ystod profion llwyth ar glwstwr Kafka, buom hefyd yn monitro ei iechyd i sicrhau nad oedd unrhyw goden yn ailgychwyn, dim atgynyrchiadau nad oedd yn cydamseru, a'r mewnbwn mwyaf posibl gyda'r amrywiadau lleiaf posibl:
- Mae'r generadur llwyth yn ysgrifennu ystadegau safonol am nifer y negeseuon a gyhoeddir a'r gyfradd gwallau. Dylai'r gyfradd gwallau aros yr un fath
0,00%. - , a ddefnyddir gan kafka-operator, yn darparu dangosfwrdd lle gallwn hefyd fonitro cyflwr y clwstwr. I weld y panel hwn gwnewch:
supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> - Lefel ISR (nifer o atgynyrchiadau “mewn-sync”) crebachu ac ehangu yn hafal i 0.
Canlyniadau mesur
3 brocer, maint y neges - 512 bytes
Gyda rhaniadau wedi'u dosbarthu'n gyfartal ar draws tri brocer, roeddem yn gallu cyflawni perfformiad ~500 Mb/s (tua 990 mil o negeseuon yr eiliad):
Nid oedd defnydd cof y peiriant rhithwir JVM yn fwy na 2 GB:
Cyrhaeddodd trwybwn disg yr uchafswm trwybwn nod I/O ar bob un o'r tri achos yr oedd y broceriaid yn rhedeg arnynt:
O'r data ar ddefnydd cof gan nodau, mae'n dilyn bod byffro system a storio wedi cymryd ~10-15 GB:
3 brocer, maint y neges - 100 bytes
Wrth i faint y neges leihau, mae trwybwn yn gostwng tua 15-20%: mae'r amser a dreulir yn prosesu pob neges yn effeithio arno. Yn ogystal, mae llwyth y prosesydd bron wedi dyblu.
Gan fod gan nodau brocer greiddiau heb eu defnyddio o hyd, gellir gwella perfformiad trwy newid cyfluniad Kafka. Nid yw hon yn dasg hawdd, felly i gynyddu trwygyrch mae'n well gweithio gyda negeseuon mwy.
4 brocer, maint y neges - 512 bytes
Gallwch chi gynyddu perfformiad clwstwr Kafka yn hawdd trwy ychwanegu broceriaid newydd a chynnal cydbwysedd rhaniadau (mae hyn yn sicrhau bod y llwyth wedi'i ddosbarthu'n gyfartal rhwng broceriaid). Yn ein hachos ni, ar ôl ychwanegu brocer, cynyddodd y trwygyrch clwstwr i ~580 Mb/s (~1,1 miliwn o negeseuon yr eiliad). Trodd y twf yn llai na'r disgwyl: esbonnir hyn yn bennaf gan anghydbwysedd rhaniadau (nid yw pob brocer yn gweithio ar frig eu galluoedd).
Arhosodd defnydd cof y peiriant JVM yn is na 2 GB:
Effeithiwyd ar waith broceriaid gyda gyriannau gan anghydbwysedd rhaniadau:
Canfyddiadau
Gellir ehangu'r dull ailadroddus a gyflwynir uchod i gwmpasu senarios mwy cymhleth sy'n cynnwys cannoedd o ddefnyddwyr, dychwelyd, diweddariadau treigl, ailgychwyn codennau, ac ati. Mae hyn i gyd yn ein galluogi i asesu terfynau galluoedd clwstwr Kafka o dan amodau amrywiol, nodi tagfeydd yn ei weithrediad a dod o hyd i ffyrdd i'w goresgyn.
Fe wnaethon ni ddylunio Supertubes i ddefnyddio clwstwr yn gyflym ac yn hawdd, ei ffurfweddu, ychwanegu / dileu broceriaid a phynciau, ymateb i rybuddion, a sicrhau bod Kafka yn gyffredinol yn gweithio'n iawn ar Kubernetes. Ein nod yw eich helpu i ganolbwyntio ar y brif dasg (“cynhyrchu” a “defnyddio” negeseuon Kafka), a gadael yr holl waith caled i Supertubes a gweithredwr Kafka.
Os oes gennych ddiddordeb mewn technolegau Banzai Cloud a phrosiectau Ffynhonnell Agored, tanysgrifiwch i'r cwmni yn , neu .
PS gan y cyfieithydd
Darllenwch hefyd ar ein blog:
- «";
- «";
- «'.
Ffynhonnell: hab.com