{"id":33803,"date":"2019-10-31T21:54:45","date_gmt":"2019-10-31T18:54:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/on-vam-ne-drook\/"},"modified":"2019-10-31T21:54:45","modified_gmt":"2019-10-31T18:54:45","slug":"on-vam-ne-drook","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/on-vam-ne-drook","title":{"rendered":"Han er ikke din Rook","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I takt med den stigende popularitet af Rook vil jeg gerne tale om de faldgruber og problemer, du kan st\u00f8de p\u00e5 undervejs.<\/p>\n

Om mig: Erfaring med administration af Ceph siden version hammer, grundl\u00e6gger af f\u00e6llesskabet t.me\/ceph_ru<\/a><\/noindex> p\u00e5 Telegram.<\/p>\n

For at underbygge mine p\u00e5stande vil jeg henvise til de anerkendte Habr (if\u00f8lge vurderingen) indl\u00e6g om problemer med Ceph. Jeg har ogs\u00e5 st\u00f8dt p\u00e5 st\u00f8rstedelen af problemerne i disse indl\u00e6g. Links til det anvendte materiale findes i slutningen af indl\u00e6gget.<\/p>\n

I indl\u00e6gget om Rook n\u00e6vner vi Ceph ikke uden grund - Rook er i bund og grund Ceph pakket ind i Kubernetes, og det betyder, at det arver alle dets problemer. Lad os starte med problemerne i Ceph.
\n<\/a><\/noindex><\/p>\n

Forenkling af clusterstyring<\/h3>\n

\nEn af fordelene ved Rook er den nemme administration af Ceph gennem Kubernetes.<\/p>\n

Men Ceph indeholder over 1000 konfigurationsparametre, og gennem Rook kan vi kun \u00e6ndre en mindre del af dem.<\/p>\n

Eksempel p\u00e5 Luminous
\n> ceph daemon mon.a config show | wc -l
\n1401<\/p><\/blockquote>\n

Rook markedsf\u00f8res som en praktisk m\u00e5de at installere og opdatere Ceph p\u00e5<\/b>
\nDer er ingen problemer med at installere Ceph uden Rook - en Ansible-playbook kan skrives p\u00e5 30 minutter, men der er masser af problemer med opdatering. <\/p>\n

Citater fra Krok's indl\u00e6g<\/i><\/p>\n

Eksempel: Forkert funktion af Crush-tunables efter opdatering fra Hammer til Jewel<\/p>\n

> ceph osd crush show-tunables
\n{
\n\u2026
\n \"straw_calc_version\": 1,
\n \"allowed_bucket_algs\": 22,
\n \"profile\": \"unknown\",
\n \"optimal_tunables\": 0,
\n\u2026
\n}<\/p><\/blockquote>\n

Men selv inden for mindre versioner kan der v\u00e6re problemer.<\/p>\n

Eksempel: Opdatering fra 12.2.6 bringer clustret i health err tilstand og betinget beskadiget PG.
\nceph.com\/releases\/v12-2-8-released<\/a><\/noindex><\/p>\n

Skal vi undlade at opdatere, vente og teste? Men vi bruger jo Rook for nemheden ved opdateringer, blandt andet.<\/p>\n

Vanskeligheder ved katastrofegenvinding af clustret i Rook <\/h3>\n

\nEksempel: OSD falder og genererer fejl. Du mist\u00e6nker, at problemet ligger i en af parametrene i konfigurationen, og du vil \u00e6ndre konfigurationen for en specifik daemon, men du kan ikke, fordi du har Kubernetes og DaemonSet.<\/p>\n

Der er ingen alternativer. ceph tell osd.Num injectargs fungerer ikke - OSD'en er jo nede.<\/p>\n

Vanskeligheder ved fejls\u00f8gning<\/h3>\n

\nFor nogle indstillinger og performance tests er det n\u00f8dvendigt at tilslutte sig socketen p\u00e5 OSD-daemonen. I Rook skal du f\u00f8rst finde den relevante container, derefter logge ind i den, opdage, at den n\u00f8dvendige fejls\u00f8gningstools mangler, og blive meget skuffet.<\/p>\n

Vanskeligheder ved sekventiel opstart af OSD<\/h3>\n

\nEksempel: OSD falder p\u00e5 OOM, rebalance starter, og derefter falder de n\u00e6ste.<\/p>\n

L\u00f8sning: Aktiv\u00e9r OSD \u00e9n ad gangen, vent p\u00e5, at den fuldt integreres i klyngen, og aktiv\u00e9r de n\u00e6ste. (L\u00e6s mere i rapporten Ceph. Anatomien af katastrofen).<\/p>\n

I tilf\u00e6lde af en baremetal-installation g\u00f8res dette let manuelt; i tilf\u00e6lde af Rook og \u00e9n OSD pr. node er der ikke mange problemer, men problemer med sekventiel aktivering opst\u00e5r, hvis OSD > 1 pr. node. <\/p>\n

Selvf\u00f8lgelig kan de l\u00f8ses, men vi implementerer Rook for at forenkle, og f\u00e5r dermed en kompleksitet.<\/p>\n

Kompleksiteten ved at finde gr\u00e6nserne for Ceph-demoner.<\/h3>\n

\nFor baremetal-installationer er det relativt enkelt at beregne de n\u00f8dvendige ressourcer til klyngen \u2014 der findes formler og forskning. Ved brug af svage CPU'er skal du stadig udf\u00f8re en r\u00e6kke ydeevnetests, finde ud af, hvad Numa er, men det er stadig lettere end i Rook.<\/p>\n

I tilf\u00e6lde af Rook pr\u00e6senteres der et sp\u00f8rgsm\u00e5l om at angive CPU-gr\u00e6nser, ud over hukommelsesgr\u00e6nserne, som kan beregnes.<\/p>\n

Her skal du virkelig arbejde med ydeevnetests. Ved at s\u00e6tte for lave gr\u00e6nser vil du f\u00e5 en langsom klynge, og ved at s\u00e6tte unlim vil du f\u00e5 aktiv CPU-brug under rebalance, hvilket vil p\u00e5virke dine applikationer i Kubernetes negativt.<\/p>\n

Netv\u00e6rksinteraktionsproblemer v1<\/h3>\n

\nFor Ceph anbefales det at bruge et 2x10gb netv\u00e6rk. \u00c9t til klienttrafik, det andet til Ceph's tjenestebehov (rebalance). Hvis du k\u00f8rer Ceph p\u00e5 baremetal, er denne opdeling let at konfigurere; hvis du lever med Rook, vil opdelingen af netv\u00e6rk give dig problemer, da langt fra hver klyngekonfiguration tillader at give to forskellige netv\u00e6rk til en pod.<\/p>\n

Netv\u00e6rksinteraktionsproblemer v2<\/h3>\n

\nHvis du v\u00e6lger ikke at dele netv\u00e6rk, vil Ceph-trafikken under rebalance blokere hele kanalen, og dine applikationer i Kubernetes vil h\u00e6mme eller falde. Du kan reducere Ceph's rebalance-hastighed, men det medf\u00f8rer en \u00f8get risiko for, at den anden node falder ud af klyngen p\u00e5 grund af diske eller OOM, og der vil derefter v\u00e6re en garanti for read-only p\u00e5 klyngen.<\/p>\n

Langsom rebalance \u2014 lange nedbrud af applikationer.<\/h3>\n

\nCitat fra posten Ceph. Anatomien af katastrofen.<\/i><\/p>\n

Ydeevne for testklyngen:<\/p>\n

En skriveoperation p\u00e5 4 Kbyte tager 1 ms, ydeevnen er 1000 operationer\/sekund i 1 tr\u00e5d.<\/p>\n

En operation p\u00e5 4 Mbyte (objektst\u00f8rrelse) tager 22 ms, ydeevnen er 45 operationer\/sekund.<\/p>\n

Derfor, n\u00e5r en af de tre dom\u00e6ner svigter, vil klyngen i et stykke tid v\u00e6re i en degraderet tilstand, og halvdelen af de varme objekter vil blive fordelt p\u00e5 forskellige versioner, hvilket betyder, at halvdelen af skriveoperationerne vil begynde med et tvunget genoprettelse.<\/p>\n

Tiden til tvunget genoprettelse beregnes omtrent \u2014 skriveoperationer til det degraderede objekt.<\/p>\n

F\u00f8rst l\u00e6ser vi 4 MB p\u00e5 22 ms, skriver 22 ms, og derefter skriver vi 4 KB reelle data p\u00e5 1 ms. Samlet set 45 ms pr. skriveoperation til det degraderede objekt p\u00e5 SSD, n\u00e5r vores normale ydelse var 1 ms \u2014 et fald i ydelsen p\u00e5 45 gange.<\/p>\n

Jo h\u00f8jere procentdel af degraderede objekter, desto v\u00e6rre bliver det.<\/p><\/blockquote>\n

Det viser sig, at hastigheden for rebalance er kritisk vigtig for klyngens korrekte funktion.<\/p>\n

Specifikke serverindstillinger for Ceph<\/h3>\n

\nCeph kr\u00e6ver nogle gange specifik tuning af v\u00e6rten. <\/p>\n

Eksempel: sysctl-indstillinger og den samme JumboFrame, nogle af disse indstillinger kan have negativ indflydelse p\u00e5 dit payload.<\/p>\n

Den virkelige n\u00f8dvendighed af Rook forbliver et sp\u00f8rgsm\u00e5l.<\/h3>\n

\nHvis du er i skyen, har du lager fra din cloud-udbyder, hvilket er meget mere praktisk. <\/p>\n

Hvis du er p\u00e5 dine egne servere, vil h\u00e5ndteringen af Ceph v\u00e6re lettere uden Kubernetes. <\/p>\n

Lejer du servere hos en eller anden low-cost hosting? S\u00e5 venter der dig masser af sjov med netv\u00e6rket, dets latens og b\u00e5ndbredde, hvilket tydeligvis har en negativ indflydelse p\u00e5 Ceph.<\/p>\n

I alt:<\/b> Implementering af Kubernetes og implementering af lager er forskellige opgaver med forskellige foruds\u00e6tninger og forskellige l\u00f8sningsmuligheder \u2014 at blande dem indeb\u00e6rer potentielt en farlig trade-off til fordel for det ene eller det andet. At kombinere disse l\u00f8sninger vil v\u00e6re meget vanskeligt selv p\u00e5 planl\u00e6gningsstadiet, og der er stadig driftsperioden.<\/p>\n

Liste over anvendt litteratur:<\/p>\n

Indl\u00e6g #1<\/a><\/noindex> Men du siger Ceph... er det virkelig s\u00e5 godt?
\nIndl\u00e6g #2<\/a><\/noindex> Ceph. Anatomien af en katastrofe
\n
Kilde: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0412 \u0441\u0432\u044f\u0437\u0438 \u0441 \u043d\u0430\u0431\u0438\u0440\u0430\u044e\u0449\u0435\u0439 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u043e\u0441\u0442\u044c\u044e Rook \u0445\u043e\u0447\u0435\u0442\u0441\u044f \u043f\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u0442\u044c \u043e \u0435\u0433\u043e \u043f\u043e\u0434\u0432\u043e\u0434\u043d\u044b\u0445 \u043a\u0430\u043c\u043d\u044f\u0445 \u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u0445, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0436\u0434\u0443\u0442 \u0432\u0430\u0441 \u043d\u0430 \u043f\u0443\u0442\u0438. \u041e \u0441\u0435\u0431\u0435: \u041e\u043f\u044b\u0442 \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f ceph \u0441 \u0432\u0435\u0440\u0441\u0438\u0438 hammer, \u043e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u043a\u043e\u043c\u044c\u044e\u043d\u0438\u0442\u0438 t.me\/ceph_ru \u0432 \u0442\u0435\u043b\u0435\u0433\u0440\u0430\u043c. \u0414\u0430\u0431\u044b \u043d\u0435 \u0431\u044b\u0442\u044c \u0433\u043e\u043b\u043e\u0441\u043b\u043e\u0432\u043d\u044b\u043c \u044f \u0431\u0443\u0434\u0443 \u0441\u0441\u044b\u043b\u0430\u0442\u044c\u0441\u044f \u043d\u0430 \u043f\u0440\u0438\u043d\u044f\u0442\u044b\u0435 \u0445\u0430\u0431\u0440\u043e\u043c (\u0441\u0443\u0434\u044f \u043f\u043e \u0440\u0435\u0439\u0442\u0438\u043d\u0433\u0443) \u043f\u043e\u0441\u0442\u044b \u043e \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u0445 \u0441 ceph. \u0421 \u0431\u041e\u043b\u044c\u0448\u0435\u0439 \u0447\u0430\u0441\u0442\u044c\u044e \u043f\u0440\u043e\u0431\u043b\u0435\u043c \u0432 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33803","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Han er ikke din dRook | ProHoster","description":"Med den stigende popularitet af Rook vil jeg gerne tale om dets faldgruber og problemerne, der venter dig p\u00e5 vejen. Om mig selv: Erfaring med administration af Ceph siden version hammer, grundl\u00e6gger af f\u00e6llesskabet","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/on-vam-ne-drook","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u043d \u0432\u0430\u043c \u043d\u0435 \u0434Rook | ProHoster","og:description":"\u0412 \u0441\u0432\u044f\u0437\u0438 \u0441 \u043d\u0430\u0431\u0438\u0440\u0430\u044e\u0449\u0435\u0439 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u043e\u0441\u0442\u044c\u044e Rook \u0445\u043e\u0447\u0435\u0442\u0441\u044f \u043f\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u0442\u044c \u043e \u0435\u0433\u043e \u043f\u043e\u0434\u0432\u043e\u0434\u043d\u044b\u0445 \u043a\u0430\u043c\u043d\u044f\u0445 \u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u0445, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0436\u0434\u0443\u0442 \u0432\u0430\u0441 \u043d\u0430 \u043f\u0443\u0442\u0438. \u041e \u0441\u0435\u0431\u0435: \u041e\u043f\u044b\u0442 \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f ceph \u0441 \u0432\u0435\u0440\u0441\u0438\u0438 hammer, \u043e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u043a\u043e\u043c\u044c\u044e\u043d\u0438\u0442\u0438","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/on-vam-ne-drook","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:54:45+00:00","article:modified_time":"2019-10-31T18:54:45+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33803","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 16:46:22","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:33:24","updated":"2026-01-21 16:46:22","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/33803","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=33803"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/33803\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=33803"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=33803"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=33803"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}