{"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\/it\/blog\/administrirovanie\/on-vam-ne-drook","title":{"rendered":"Lui non \u00e8 un dRook","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Con l'aumento della popolarit\u00e0 di Rook, voglio parlare delle sue insidie e dei problemi che vi attendono lungo il cammino.<\/p>\n

Su di me: Esperienza nella gestione di ceph dalla versione hammer, fondatore della community. t.me\/ceph_ru<\/a><\/noindex> su telegram.<\/p>\n

Per non essere vago, far\u00f2 riferimento ai post accettati da Habr (secondo la valutazione) riguardo ai problemi con ceph. Ho anche affrontato la maggior parte dei problemi menzionati in questi post. I link ai materiali utilizzati alla fine del post.<\/p>\n

Nel post su Rook, menzioniamo ceph non per caso: Rook \u00e8 essenzialmente ceph avvolto in kubernetes, quindi eredita tutti i suoi problemi. Iniziamo con i problemi di ceph.
\n<\/a><\/noindex><\/p>\n

Semplificazione della gestione del cluster<\/h3>\n

\nUno dei vantaggi di Rook \u00e8 la facilit\u00e0 di gestione di ceph tramite kubernetes.<\/p>\n

Tuttavia, ceph contiene oltre 1000 parametri di configurazione, mentre tramite rook possiamo modificare solo una parte minore di essi.<\/p>\n

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

Rook \u00e8 posizionato come un modo conveniente per installare e aggiornare ceph.<\/b>
\nNon ci sono problemi nell'installare ceph senza Rook: un playbook ansible si scrive in 30 minuti, mentre l'aggiornamento presenta molte difficolt\u00e0. <\/p>\n

Citazione dal post di Krok<\/i><\/p>\n

Esempio: comportamento errato dei tunables crush dopo l'aggiornamento da hummer a 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

Ma anche all'interno delle versioni minori ci possono essere problemi.<\/p>\n

Esempio: Aggiornamento 12.2.6 che porta il cluster a uno stato di health err e PG teoricamente danneggiato.
\nceph.com\/releases\/v12-2-8-released<\/a><\/noindex><\/p>\n

Non aggiornare, attendere e testare? Ma stiamo usando Rook proprio per la comodit\u00e0 degli aggiornamenti.<\/p>\n

Difficolt\u00e0 nel disaster recovery del cluster in Rook <\/h3>\n

\nEsempio: OSD si arresta con errori che si presentano continuamente. Sospettate che il problema sia in uno dei parametri della configurazione, volete modificare la configurazione per un demone specifico, ma non potete, perch\u00e9 avete kubernetes e DaemonSet.<\/p>\n

Non ci sono alternative. ceph tell osd.Num injectargs non funziona: l'OSD \u00e8 inattivo.<\/p>\n

Difficolt\u00e0 di debug<\/h3>\n

\nPer alcune impostazioni e test delle performance \u00e8 necessario collegarsi direttamente alla socket del demone osd. Nel caso di Rook, \u00e8 necessario prima trovare il container giusto, poi accedervi, scoprire che il tool di debug \u00e8 assente e rimanere molto delusi.<\/p>\n

Difficolt\u00e0 nel sollevare OSD in sequenza<\/h3>\n

\nEsempio: OSD si arresta per OOM, inizia il ribalancing, e successivamente si arrestano i successivi.<\/p>\n

Soluzione: Alzare l'OSD uno alla volta, attendere il suo completo avvio nel cluster e sollevare il successivo. (Maggiori dettagli nel report Ceph. Anatomia dei disastri).<\/p>\n

Nel caso di installazioni baremetal, questo si fa facilmente a mano; nel caso di Rook con un OSD per nodo, non ci sono particolari problemi, mentre sorgeranno problemi di avvio sequenziale se OSD > 1 per nodo. <\/p>\n

Certo, sono risolvibili, ma noi portiamo Rook per semplificare e otteniamo complicazioni.<\/p>\n

Difficolt\u00e0 nella definizione dei limiti per i demoni ceph.<\/h3>\n

\nPer l'installazione baremetal di ceph \u00e8 abbastanza facile calcolare le risorse necessarie per il cluster: ci sono formule e ricerche disponibili. Con CPU deboli, dovrai comunque eseguire una serie di test delle prestazioni e comprendere cosa significhi Numa, ma \u00e8 comunque pi\u00f9 semplice rispetto a Rook.<\/p>\n

Nel caso di Rook, oltre ai limiti di memoria che possono essere calcolati, sorgerebbe il problema di impostare il limite CPU.<\/p>\n

E qui dovrai sudare con i test delle prestazioni. In caso di limiti sottovalutati, avrai un cluster lento; se imposti un limite illimitato, sperimenterai un utilizzo intenso della CPU durante il bilanciamento, il che influir\u00e0 negativamente sulle tue applicazioni in Kubernetes.<\/p>\n

Problemi con l'interazione di rete v1.<\/h3>\n

\nPer ceph, si raccomanda di utilizzare una rete 2x10Gb. Una per il traffico client e l'altra per le necessit\u00e0 di servizio di ceph (bilanciamento). Se vivi con ceph su baremetal, questa separazione \u00e8 facile da configurare; se utilizzi Rook, la separazione delle reti potrebbe causarti problemi, poich\u00e9 non tutti i config dei cluster consentono di presentare al pod due reti diverse.<\/p>\n

Problemi con l'interazione di rete v2.<\/h3>\n

\nSe decidi di non separare le reti, durante il bilanciamento il traffico ceph saturer\u00e0 l'intero canale e le tue applicazioni in Kubernetes rallenteranno o potrebbero andare in crash. Puoi ridurre la velocit\u00e0 di bilanciamento di ceph, ma in questo modo, a causa di un lungo bilanciamento, aumenti il rischio che il secondo nodo esca dal cluster a causa di problemi con i dischi o OOM, il che porta a un accesso garantito in sola lettura sul cluster.<\/p>\n

Bilanciamento lungo \u2014 lunghe attese per le applicazioni.<\/h3>\n

\nCitazione dal post Ceph. Anatomia dei disastri.<\/i><\/p>\n

Prestazioni del cluster di test:<\/p>\n

Un'operazione di scrittura di 4 KByte richiede 1 ms, con una capacit\u00e0 di 1000 operazioni al secondo in 1 thread.<\/p>\n

Un'operazione di 4 MByte (dimensione dell'oggetto) richiede 22 ms, con una capacit\u00e0 di 45 operazioni al secondo.<\/p>\n

Pertanto, quando uno dei tre domini fallisce, il cluster rimane per un certo tempo in uno stato degradato, e met\u00e0 degli oggetti caldi si distribuisce su diverse versioni, quindi met\u00e0 delle operazioni di scrittura inizier\u00e0 con un ripristino forzato.<\/p>\n

Il tempo di ripristino forzato viene calcolato approssimativamente: operazioni di scrittura su un oggetto degradato.<\/p>\n

Prima leggiamo 4 MB in 22 ms, scriviamo in 22 ms e poi in 1 ms scriviamo 4 KB di dati propri. In totale, 45 ms per un'operazione di scrittura su un oggetto degradato su SSD, quando la prestazione standard era di 1 ms: un calo delle prestazioni di 45 volte.<\/p>\n

Pi\u00f9 alto \u00e8 il nostro percentuale di oggetti degradati, pi\u00f9 la situazione diventa critica.<\/p><\/blockquote>\n

Dunque, la velocit\u00e0 di bilanciamento \u00e8 estremamente importante per il corretto funzionamento del cluster.<\/p>\n

Impostazioni specifiche dei server per ceph<\/h3>\n

\nceph potrebbe necessitare di una specifica ottimizzazione dell'host. <\/p>\n

Esempio: impostazioni sysctl e lo stesso JumboFrame, alcune di queste impostazioni possono influenzare negativamente il vostro payload.<\/p>\n

La reale necessit\u00e0 di Rook rimane in discussione<\/h3>\n

\nSe siete nel cloud, avete uno storage dal vostro fornitore di cloud, il che \u00e8 decisamente pi\u00f9 comodo. <\/p>\n

Se siete sui vostri server, la gestione di ceph sar\u00e0 pi\u00f9 semplice senza kubernetes. <\/p>\n

State affittando server in un hosting a basso costo? Allora vi aspettano molte sfide con la rete, le sue latenze e la larghezza di banda, che influiscono negativamente su ceph.<\/p>\n

In totale:<\/b> L'implementazione di kubernetes e l'implementazione dello storage sono compiti diversi con vari input e diverse opzioni di soluzione: mescolarli significa fare un potenziale trade-off rischioso a favore dell'uno o dell'altro. Combinare queste soluzioni sar\u00e0 molto difficile anche in fase di progettazione, e c'\u00e8 anche un periodo di esercizio.<\/p>\n

Elenco della letteratura utilizzata:<\/p>\n

Post #1<\/a><\/noindex> Ma voi dite Ceph\u2026 \u00e8 davvero cos\u00ec buono?
\nPost #2<\/a><\/noindex> Ceph. Anatomia di un disastro
\n
Fonte: 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\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\udd47Non \u00e8 per te dRook | ProHoster","description":"Con l'aumento della popolarit\u00e0 di Rook, \u00e8 interessante parlare delle sue insidie e dei problemi che vi aspettano lungo il cammino. Su di me: Esperienza nell'amministrazione di ceph dalla versione hammer, fondatore della community","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/on-vam-ne-drook","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/33803","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=33803"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/33803\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=33803"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=33803"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=33803"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}