Танилцуулга

Хэсэг хугацааны өмнө надад ачааллын кластер боловсруулах даалгавар өгсөн PostgreSQL, нэг хотын дотор шилэн кабелиар холбогдсон хэд хэдэн дата төвд ажиллаж, нэг дата төвийн эвдрэлийг (жишээ нь унтарсан) тэсвэрлэх чадвартай. Гэмтлийг тэсвэрлэх чадвартай програм хангамжийн хувьд би сонгосон ХэмУчир нь энэ нь RedHat-аас бүтэлгүйтлийн кластер үүсгэх албан ёсны шийдэл юм. RedHat үүнийг дэмждэг, мөн энэ шийдэл нь бүх нийтийн (модульч) учраас сайн хэрэг. Үүний тусламжтайгаар та зөвхөн PostgreSQL төдийгүй бусад үйлчилгээний стандарт модулиудыг ашиглах эсвэл тодорхой хэрэгцээнд зориулж үүсгэх боломжтой.

Энэ шийдвэр нь үндэслэлтэй асуултыг бий болгосон: бүтэлгүйтсэн кластер нь алдааг хэр тэсвэрлэх вэ? Үүнийг судлахын тулд би кластерын зангилаанууд дээрх янз бүрийн эвдрэлийг дуурайж, үйлчилгээг сэргээхийг хүлээж, бүтэлгүйтсэн зангилааг сэргээж, туршилтыг давталтаар үргэлжлүүлэх туршилтын вандан зохион бүтээсэн. Энэ төслийг анх hapgsql гэж нэрлэдэг байсан ч цаг хугацаа өнгөрөх тусам ганцхан эгшигтэй нэрнээс залхсан. Тиймээс би алдааг тэсвэрлэх чадвартай мэдээллийн баазуудыг дуудаж эхэлсэн (мөн тэдгээрт чиглүүлдэг хөвөгч IP) кроган (бүх чухал эрхтнүүд нь давхардсан компьютерийн тоглоомын дүр), зангилаа, кластер, төсөл нь өөрөө тучанка (крогануудын амьдардаг гараг).

Одоо удирдлага зөвшөөрлөө MIT лицензийн дагуу нээлттэй эх сурвалжийн нийгэмлэгт төслийг нээх. README удахгүй англи хэл рүү орчуулагдах болно (учир нь гол хэрэглэгчид нь Pacemaker болон PostgreSQL хөгжүүлэгчид байх төлөвтэй байгаа тул) би энэ нийтлэлийн хэлбэрээр README-ийн хуучин орос хувилбарыг (хэсэгчилсэн) танилцуулахаар шийдлээ.

Кластеруудыг виртуал машинууд дээр байрлуулдаг VirtualBox. Нийтдээ 12 виртуал машин (нийтдээ 36GiB) байршуулах бөгөөд энэ нь 4 гэмтэлд тэсвэртэй кластер (өөр өөр сонголт) үүсгэдэг. Эхний хоёр кластер нь өөр өөр мэдээллийн төвд байрладаг хоёр PostgreSQL сервер, нийтлэг серверээс бүрдэнэ. гэрч c чуулгын төхөөрөмж (гурав дахь өгөгдлийн төвд хямд виртуал машин дээр байрлуулсан), тодорхойгүй байдлыг шийддэг 50% / 50%, аль нэгэн намд саналаа өгөх. Гурван мэдээллийн төвд гурав дахь кластер: нэг мастер, хоёр боол, үгүй чуулгын төхөөрөмж. Дөрөв дэх кластер нь дөрвөн PostgreSQL серверээс бүрдэх бөгөөд нэг дата төвд хоёр нь: нэг мастер, бусад нь хуулбар, мөн ашигладаг. гэрч c чуулгын төхөөрөмж. Дөрөв дэх нь хоёр сервер эсвэл нэг мэдээллийн төвийн эвдрэлийг тэсвэрлэх чадвартай. Шаардлагатай бол энэ шийдлийг илүү олон тооны хуулбар болгон өргөжүүлж болно.

Цагийн нарийвчлалтай үйлчилгээ ntpd мөн алдааг тэсвэрлэхийн тулд дахин тохируулсан боловч энэ аргыг өөрөө ашигладаг ntpd (өнчин горим). Хуваалцсан сервер гэрч нь төв NTP серверийн үүрэг гүйцэтгэж, бүх кластерт цагаа хуваарилж, ингэснээр бүх серверүүдийг өөр хоорондоо синхрончлох болно. Хэрэв гэрч амжилтгүй болсон эсвэл тусгаарлагдсан бол кластер серверүүдийн аль нэг нь (кластер дотор) цагаа хуваарилж эхэлнэ. Туслах кэш HTTP прокси хүртэл өсгөсөн гэрч, түүний тусламжтайгаар бусад виртуал машинууд Yum репозиторуудад хандах боломжтой. Бодит байдал дээр үнэн зөв цаг, прокси гэх мэт үйлчилгээг тусгай зориулалтын серверүүд дээр байршуулах боловч лангуун дээр байршуулдаг. гэрч зөвхөн виртуал машинуудын тоо болон зайг хэмнэхийн тулд.

Хувилбарууд

v0. VirtualBox 7 дээр CentOS 11 болон PostgreSQL 6.1-тэй ажилладаг.

Кластер бүтэц

Бүх кластерууд нь олон өгөгдлийн төвд байрлах, нэг хавтгай сүлжээнд нэгтгэгдэх зориулалттай бөгөөд нэг дата төвийн доголдол эсвэл сүлжээний тусгаарлалтыг тэсвэрлэх ёстой. Тийм ч учраас боломжгүй юм хамгаалах зорилгоор ашиглах хуваагдмал тархи гэж нэрлэдэг стандарт зүрхний аппарат технологи СТОНИТ (Толгой дахь нөгөө зангилааг буудах) эсвэл хашаа барих. Үүний мөн чанар: хэрэв кластер дахь зангилаанууд ямар нэг зангилаанд ямар нэг зүйл буруу байна гэж сэжиглэж эхэлбэл энэ нь хариу өгөхгүй эсвэл буруу ажиллаж байгаа бол түүнийг "гадаад" төхөөрөмж, жишээлбэл, IPMI эсвэл UPS хяналтын картаар дамжуулан албадан унтраадаг. . Гэхдээ энэ нь ганц удаа доголдсон тохиолдолд IPMI эсвэл UPS сервер үргэлжлүүлэн ажиллах тохиолдолд л ажиллах болно. Энд бид мэдээллийн төв бүхэлдээ доголдох үед (жишээлбэл, эрчим хүчээ алдах) илүү их сүйрлээс хамгаалахаар төлөвлөж байна. Мөн ийм татгалзсанаар бүх зүйл стонит-төхөөрөмжүүд (IPMI, UPS гэх мэт) мөн ажиллахгүй.

Үүний оронд тогтолцоо нь чуулгын санаан дээр суурилдаг. Бүх зангилаанууд дуу хоолойтой бөгөөд зөвхөн бүх зангилааны талаас илүүг харж чаддаг хүмүүс л ажиллах боломжтой. Энэ "хагас + 1" хэмжигдэхүүнийг нэрлэдэг чуулга. Хэрэв чуулгад хүрээгүй бол зангилаа нь сүлжээний тусгаарлалтад байгаа гэж шийдэж, нөөцөө унтраах ёстой, өөрөөр хэлбэл. энэ бол юу вэ хуваагдмал тархины хамгаалалт. Хэрэв энэ зан үйлийг хариуцдаг програм хангамж ажиллахгүй бол жишээлбэл IPMI дээр суурилсан харуул ажиллах шаардлагатай болно.

Хэрэв зангилааны тоо тэгш бол (хоёр мэдээллийн төв дэх кластер) тодорхой бус байдал үүсч болно. 50% / 50% (тавь тавь) сүлжээний тусгаарлалт нь кластерыг яг хагасаар хуваах үед. Тиймээс тэгш тооны зангилааны хувьд бид нэмнэ чуулгын төхөөрөмж нь гуравдагч дата төвд хамгийн хямд виртуал машин дээр ажиллуулж болох энгийн демон юм. Тэрээр саналаа сегментүүдийн аль нэгэнд (түүний харсан) өгч, улмаар 50%/50% тодорхойгүй байдлыг шийддэг. Би чуулгын төхөөрөмжийг ажиллуулах серверийг нэрлэсэн гэрч (repmgr-ийн нэр томъёо, надад таалагдсан).

Нөөцийг нэг газраас нөгөө рүү, жишээлбэл, алдаатай серверээс эрүүл сервер рүү эсвэл системийн администраторын тушаалаар шилжүүлж болно. Үйлчлүүлэгчид шаардлагатай нөөцүүд хаана байгааг мэдэхийн тулд (хаана холбогдох вэ?), хөвөгч IP (хөвөгч IP). Эдгээр нь Pacemaker-ийн зангилааны эргэн тойронд хөдөлж чадах IP хаягууд юм (бүх зүйл хавтгай сүлжээнд байдаг). Тэдгээр нь тус бүр нь нөөц (үйлчилгээ) -ийг бэлгэддэг бөгөөд энэ үйлчилгээнд нэвтрэхийн тулд холбогдох шаардлагатай газарт байрлах болно (манай тохиолдолд мэдээллийн сан).

Тучанка1 (нягшилттай хэлхээ)

бүтэц

Бидэнд ачаалал багатай олон жижиг өгөгдлийн сангууд байдаг бөгөөд үүний тулд зөвхөн уншигдах гүйлгээнд зориулагдсан боол серверийг халуун зогсолтын горимд байлгах нь ашиггүй юм (нөөцийг ингэж үрэх шаардлагагүй).

Дата төв бүр нэг сервертэй. Сервер бүр PostgreSQL-ийн хоёр тохиолдолтой (PostgreSQL-ийн нэр томъёогоор тэдгээрийг кластер гэж нэрлэдэг, гэхдээ эндүүрэл гаргахгүйн тулд би тэдгээрийг жишээнүүд гэж нэрлэх болно (бусад мэдээллийн баазтай адилтгаж), би зөвхөн Pacemaker кластеруудыг кластер гэж нэрлэх болно). Нэг жишээ нь мастер горимд ажилладаг бөгөөд зөвхөн үйлчилгээ үзүүлдэг (зөвхөн хөвөгч IP нь түүнд хүргэдэг). Хоёрдахь хувилбар нь хоёр дахь дата төвийн боол болж ажилладаг бөгөөд зөвхөн эзэн нь амжилтгүй болсон тохиолдолд л үйлчилгээ үзүүлэх болно. Ихэнх тохиолдолд хоёрын нэг нь (мастер) үйлчилгээ үзүүлдэг (хүсэлтүүдийг гүйцэтгэдэг) тул серверийн бүх нөөцийг мастерт зориулж оновчтой болгодог (санах ой нь shared_buffers кэшэд зориулагдсан гэх мэт), гэхдээ хоёр дахь тохиолдол нь Мэдээллийн төвүүдийн аль нэг нь бүтэлгүйтсэн тохиолдолд хангалттай нөөцтэй (файлын системийн кэшээр дамжуулан оновчтой бус ажиллах боломжтой). Кластер хэвийн ажиллаж байх үед боол үйлчилгээ үзүүлдэггүй (зөвхөн унших хүсэлтийг гүйцэтгэдэггүй), ингэснээр нэг машин дээр мастертай нөөцийн төлөөх дайн гарахгүй.

Хоёр зангилааны хувьд алдааг тэсвэрлэх чадвар нь зөвхөн асинхрон хуулбарлах үед л боломжтой байдаг, учир нь синхрон хуулбарлах үед боолын бүтэлгүйтэл нь эзэн зогсоход хүргэдэг.

Гэрч өгөхгүй байх

гэрчлэхгүй байх (чуулгын төхөөрөмж) Би зөвхөн Tuchanka1 кластерын хувьд авч үзэх болно, бусад бүхний хувьд энэ нь ижил түүх байх болно. Хэрэв гэрч амжилтгүй болвол кластерийн бүтцэд юу ч өөрчлөгдөхгүй, бүх зүйл өмнөх шигээ ажиллах болно. Гэхдээ чуулга 2-аас 3 болж, улмаар дараагийн бүтэлгүйтэл нь кластерт үхэлд хүргэх болно. Үүнийг яаралтай засах шаардлагатай хэвээр байх болно.

Тучанка1 татгалзсан

Tuchanka1-ийн мэдээллийн төвүүдийн нэг нь бүтэлгүйтсэн. Энэ тохиолдолд гэрч хоёр дахь мэдээллийн төвийн хоёр дахь зангилаанд саналаа өгнө. Тэнд хуучин боол нь мастер болж хувирдаг бөгөөд үүний үр дүнд мастер хоёулаа нэг сервер дээр ажилладаг бөгөөд тэдний хөвөгч IP хоёулаа тэднийг зааж өгдөг.

Тучанка2 (сонгодог)

бүтэц

Хоёр зангилааны сонгодог схем. Нэгэн дээр эзэн, хоёр дахь дээр нь боол ажилладаг. Хоёулаа хүсэлтийг гүйцэтгэх боломжтой (зарц нь зөвхөн унших боломжтой), тиймээс хоёуланг нь хөвөгч IP-ээр заадаг: krogan2 нь эзэн, krogan2s1 нь боол юм. Эзэн, боол хоёулаа алдааг тэсвэрлэх чадвартай байх болно.

Хоёр зангилааны хувьд алдааг тэсвэрлэх чадвар нь зөвхөн асинхрон хуулбарлах үед л боломжтой байдаг, учир нь синхрон хуулбарлах үед боолын бүтэлгүйтэл нь мастерийг зогсооход хүргэдэг.

Тучанка2 татгалзсан

Хэрэв мэдээллийн төвүүдийн аль нэг нь ажиллахаа больсон бол гэрч хоёр дахь нь саналаа. Цорын ганц ажиллаж байгаа өгөгдлийн төвд мастер дээшлэх бөгөөд хөвөгч IP хоёулаа түүн рүү чиглэнэ: мастер ба боол. Мэдээжийн хэрэг, инстанц нь мастер болон slave хөвөгч IP-ийн бүх холболт, хүсэлтийг нэгэн зэрэг хүлээн авах хангалттай нөөцтэй байхаар (холболтын хязгаарлалт гэх мэт) тохируулагдсан байх ёстой. Өөрөөр хэлбэл, хэвийн ажиллагааны үед энэ нь хангалттай хязгаарлалттай байх ёстой.

Тучанка4 (олон боол)

бүтэц

Аль хэдийн өөр нэг туйл. Зөвхөн унших боломжтой маш олон хүсэлтийг хүлээн авдаг мэдээллийн сангууд байдаг (ачаалал ихтэй сайтын ердийн тохиолдол). Tuchanka4 бол ийм хүсэлтийг шийдвэрлэх гурав ба түүнээс дээш боол байж болох ч тийм ч олон биш байх нөхцөл юм. Маш олон тооны боолуудтай бол шаталсан хуулбарлах системийг зохион бүтээх шаардлагатай болно. Хамгийн бага тохиолдолд (зураг дээр) хоёр дата төв тус бүр нь PostgreSQL жишээ бүхий хоёр сервертэй.

Энэ схемийн өөр нэг онцлог нь нэг синхрон хуулбарыг зохион байгуулах боломжтой болсон явдал юм. Энэ нь хэрэв боломжтой бол мастертай ижил мэдээллийн төвд хуулбарлахаас илүү өөр мэдээллийн төвд хуулбарлахаар тохируулагдсан. Мастер болон боол бүрийг хөвөгч IP зааж өгдөг. Аз болоход, боолуудын хооронд ямар нэгэн байдлаар хүсэлтийг тэнцвэржүүлэх шаардлагатай болно sql проксижишээлбэл, үйлчлүүлэгчийн талд. Өөр өөр төрлийн үйлчлүүлэгчид өөр өөр төрлийг шаардаж болно sql прокси, хэнд юу хэрэгтэйг зөвхөн үйлчлүүлэгч хөгжүүлэгчид л мэддэг. Энэ функцийг гадны демон эсвэл клиент номын сан (холболтын сан) гэх мэтээр хэрэгжүүлж болно. Энэ бүхэн нь өгөгдлийн сангийн кластер (failover SQL прокси Үйлчлүүлэгчийн алдааг тэсвэрлэх чадварын хамт бие даан хэрэгжүүлэх боломжтой).

Тучанка4 татгалзсан

Хэрэв нэг дата төв (жишээ нь, хоёр сервер) бүтэлгүйтвэл гэрч хоёр дахь нь саналаа өгнө. Үүний үр дүнд хоёр дахь өгөгдлийн төвд хоёр сервер ажиллаж байна: нэг нь мастер ажиллуулж байгаа бөгөөд мастер хөвөгч IP нь түүн рүү зааж өгдөг (унших, бичих хүсэлтийг хүлээн авах); мөн хоёр дахь сервер дээр синхрон репликацтай ажиллаж байгаа slave байгаа бөгөөд slave float IP-ийн нэг нь түүн рүү чиглэдэг (зөвхөн унших хүсэлтэд).

Хамгийн түрүүнд анхаарах зүйл бол бүх боол хөвөгч IP нь ажилчид биш, харин зөвхөн нэг юм. Түүнтэй зөв ажиллахын тулд үүнийг хийх шаардлагатай болно sql прокси бүх хүсэлтийг үлдсэн цорын ганц хөвөгч IP рүү шилжүүлсэн; мөн хэрэв sql прокси үгүй, тэгвэл та холболтын URL дээр таслалаар тусгаарлагдсан бүх хөвөгч IP боолуудыг жагсааж болно. Энэ тохиолдолд хамт libpq холболт нь анхны ажиллаж буй IP-тэй байх бөгөөд үүнийг автомат туршилтын системд хийдэг. Магадгүй бусад номын санд, жишээлбэл, JDBC, энэ нь ажиллахгүй бөгөөд шаардлагатай байж магадгүй юм sql прокси. Энэ нь боолуудад зориулсан хөвөгч IP-г нэг сервер дээр зэрэг үүсгэхийг хориглодог тул тэдгээр нь хэд хэдэн ажиллаж байгаа бол боол серверүүдэд жигд тархдаг тул үүнийг хийсэн болно.

Хоёрдугаарт: Дата төвийн доголдол гарсан ч синхрон хуулбарыг хадгалах болно. Хоёрдогч доголдол гарсан ч, тухайлбал, үлдсэн дата төвийн хоёр серверийн аль нэг нь доголдсон ч кластер үйлчилгээ үзүүлэхээ больсон ч үйлдсэнийхээ баталгааг өгсөн бүх хийсэн гүйлгээний талаарх мэдээллийг хадгалсаар байх болно. (хоёрдогч гэмтэл гарсан тохиолдолд алдагдлын мэдээлэл байхгүй болно).

Tuchanka3 (3 дата төв)

бүтэц

Энэ нь бүрэн ажиллагаатай гурван мэдээллийн төвтэй, тус бүр нь бүрэн ажиллагаатай мэдээллийн сангийн сервертэй нөхцөл байдалд зориулагдсан кластер юм. Энэ тохиолдолд чуулгын төхөөрөмж хэрэггүй. Нэг дата төвд мастер, нөгөө хоёр нь боолоор ажилладаг. Хуулбарлах нь синхрон бөгөөд ANY (боол1, боол2) гэж бичнэ, өөрөөр хэлбэл боолуудын аль нэг нь амлалтаа хүлээн зөвшөөрсөн гэж хамгийн түрүүнд хариу өгөх үед үйлчлүүлэгч үүрэг хариуцлагын баталгаа хүлээн авах болно. Нөөцүүдийг мастерын хувьд нэг хөвөгч IP, боолын хувьд хоёрыг заана. Tuchanka4-ээс ялгаатай нь бүх гурван хөвөгч IP нь алдааг тэсвэрлэдэг. Зөвхөн уншигдах SQL асуулгыг тэнцвэржүүлэхийн тулд та ашиглаж болно sql прокси (тусдаа алдааг тэсвэрлэх чадвартай) эсвэл нэг боол хөвөгч IP-г харилцагчдын тэн хагаст, нөгөө хагасыг нь хоёрдугаарт онооно.

Тучанка3 татгалзсан

Дата төвүүдийн аль нэг нь бүтэлгүйтвэл хоёр нь үлдэнэ. Нэгд нь мастер болон хөвөгч IP-г мастераас, хоёрдугаарт - боол болон хоёуланг нь боол хөвөгч IP-үүдийг өсгөсөн (энэ нь хоёр боол хөвөгч IP-ийн бүх холболтыг хүлээн авахын тулд нөөцийн давхар нөөцтэй байх ёстой). Мастер болон боолуудын хоорондох синхрон хуулбар. Мөн кластер нь хоёр дата төвийг устгасан тохиолдолд (хэрэв тэдгээрийг нэгэн зэрэг устгаагүй бол) хийсэн болон баталгаажуулсан гүйлгээний талаарх мэдээллийг хадгалах болно (мэдээлэл алдагдахгүй).

Би файлын бүтэц, байршуулалтын дэлгэрэнгүй тайлбарыг оруулахгүй байхаар шийдсэн. Тоглохыг хүссэн хэн бүхэн README-ээс бүгдийг нь унших боломжтой. Би зөвхөн автоматжуулсан туршилтын тайлбарыг өгч байна.

Туршилтын автомат систем

Төрөл бүрийн эвдрэлийг загварчлах замаар кластеруудын эвдрэлийг тэсвэрлэх чадварыг шалгахын тулд автомат туршилтын системийг бий болгосон. Скриптээр эхлүүлсэн test/failure. Скрипт нь таны шалгахыг хүссэн кластеруудын тоог параметр болгон авч болно. Жишээлбэл, энэ тушаал:

test/failure 2 3

зөвхөн хоёр, гурав дахь кластерийг турших болно. Хэрэв параметрүүдийг заагаагүй бол бүх кластеруудыг шалгана. Бүх кластеруудыг зэрэгцүүлэн шалгаж, үр дүнг tmux самбар дээр харуулна. Tmux нь зориулалтын tmux сервер ашигладаг тул скриптийг анхдагч tmux доороос ажиллуулж, үүрлэсэн tmux үүсгэдэг. Би терминалыг том цонхонд, жижиг фонтоор ашиглахыг зөвлөж байна. Туршилт эхлэхээс өмнө скрипт дуусах үед бүх виртуал машинуудыг агшин зуурын зураг руу буцаана. setup.

Терминал нь шалгагдсан кластеруудын тоогоор баганад хуваагддаг бөгөөд анхдагч байдлаар (дэлгэцийн зураг дээр) дөрөв байдаг. Би Тучанка2-ын жишээн дээр баганын агуулгыг тайлбарлах болно. Дэлгэцийн зураг дээрх самбарууд дугаарлагдсан байна:

1. Туршилтын статистикийг энд харуулав. Баганууд:
   • алдаа — алдааг дуурайдаг тестийн нэр (скрипт дэх функц).
   • урвал — кластерийн ажиллагааг сэргээх секундээр хэмжигдэх арифметик дундаж хугацаа. Энэ нь алдааг дуурайж буй скриптийн эхлэлээс эхлээд кластер өөрийн үйл ажиллагаагаа сэргээж, үйлчилгээгээ үргэлжлүүлэх хүртэл хэмжигддэг. Хэрэв хугацаа маш богино бол, жишээлбэл, зургаан секунд (энэ нь хэд хэдэн боолтой кластеруудад тохиолддог (Тучанка3 ба Тучанка4)), энэ нь асинхрон боол дээр алдаа гарсан бөгөөд гүйцэтгэлд ямар ч байдлаар нөлөөлөөгүй гэсэн үг юм. кластер төлөвийн унтраалга.
   • хазайлт — үнэ цэнийн тархалтыг (нарийвчлал) харуулна урвал стандарт хазайлтын аргыг ашиглан.
   • тоолох - энэ туршилтыг хэдэн удаа хийсэн бэ.
2. Богино бүртгэл нь кластер одоо юу хийж байгааг үнэлэх боломжийг танд олгоно. Давталтын (туршилтын) дугаар, цагийн тэмдэг, үйлдлийн нэрийг харуулна. Хэт удаан (5 минутаас дээш) гүйх нь асуудал байгааг илтгэнэ.
3. зүрх (зүрх) - одоогийн цаг. Гүйцэтгэлийг нүдээр үнэлэх зорилгоор мастерууд Хөвөгч IP мастер ашиглан одоогийн цагийг өөрийн хүснэгтэд байнга бичдэг. Хэрэв амжилттай бол үр дүн нь энэ самбарт харагдана.
4. цохих (импульс) - өмнө нь скриптээр тэмдэглэгдсэн "одоогийн цаг" зүрх эзэмших, одооноос уншина уу боол өөрийн хөвөгч IP-ээр дамжуулан. Боол болон хуулбарын гүйцэтгэлийг нүдээр үнэлэх боломжийг танд олгоно. Tuchanka1-д хөвөгч IP-тэй боол байхгүй (үйлчилгээ үзүүлдэг боол байхгүй), гэхдээ хоёр тохиолдол (DB) байгаа тул энд харуулахгүй. цохихболон зүрх хоёр дахь тохиолдол.
5. Хэрэгслийг ашиглан кластерын эрүүл мэндэд хяналт тавих pcs mon. Бүтэц, зангилаа хоорондын нөөцийн хуваарилалт болон бусад хэрэгтэй мэдээллийг харуулна.
6. Кластер дахь виртуал машин бүрийн системийн хяналтыг энд харуулав. Кластерт хэдэн виртуал машин байгаагаас хамааран ийм самбар илүү олон байж болно. Хоёр график CPU ачаалал (виртуал машин нь хоёр процессортой), виртуал машины нэр, Системийн ачаалал (5, 10, 15 минутын дундажаар хэмжигддэг тул Ачааллын дундаж гэж нэрлэсэн), өгөгдөл боловсруулах, санах ойн хуваарилалт.
7. Туршилт хийж буй скриптийн ул мөр. Гэнэтийн үйл ажиллагаа тасалдсан эсвэл эцэс төгсгөлгүй хүлээх мөчлөг - эвдрэл гарсан тохиолдолд энэ зан үйлийн шалтгааныг эндээс харж болно.

Туршилтыг хоёр үе шаттайгаар явуулдаг. Нэгдүгээрт, скрипт нь бүх төрлийн тестийг дамжуулж, энэ тестийг ашиглах виртуал машиныг санамсаргүй байдлаар сонгоно. Дараа нь төгсгөлгүй туршилтын мөчлөг хийгдэж, виртуал машинууд болон алдааг санамсаргүй байдлаар сонгоно. Туршилтын скриптийг гэнэт дуусгах (доод талын самбар) эсвэл ямар нэг зүйлийг хүлээх эцэс төгсгөлгүй давталт (нэг үйлдлийг гүйцэтгэх хугацаа 5 минутаас их, үүнийг ул мөрөөс харж болно) энэ кластер дээрх зарим туршилт амжилтгүй болсныг харуулж байна.

Туршилт бүр нь дараах үйлдлүүдээс бүрдэнэ.

1. Алдааг дуурайдаг функцийг ажиллуул.
2. Бэлэн үү? - кластерыг сэргээхийг хүлээж байна (бүх үйлчилгээ үзүүлэх үед).
3. Кластер сэргээх хугацааг харуулна (урвал).
4. Үзнэ үү - кластерыг "засвар" хийж байна. Үүний дараа энэ нь бүрэн ажиллагаатай байдалд буцаж, дараагийн эвдрэлд бэлэн байх ёстой.

Тестүүдийн жагсаалт нь юу хийж байгааг нь тайлбарлав:

• Сэрээ бөмбөг: Сэрээтэй бөмбөг ашиглан "Санах ой дутуу" үүсгэнэ.
• OutOfSpace: Хатуу диск дүүрсэн байна. Гэхдээ тест нь бэлгэдлийн шинж чанартай бөгөөд туршилтын явцад өчүүхэн ачаалал ихтэй байдаг тул хатуу диск дүүрсэн үед PostgreSQL ихэвчлэн бүтэлгүйтдэг.
• Postgres-KILL: тушаалаар PostgreSQL-г устгадаг killall -KILL postgres.
• Postgres-STOP: PostgreSQL командыг өлгөх killall -STOP postgres.
• Унтраах: командын тусламжтайгаар виртуал машиныг "эрчимгүй болгодог" VBoxManage controlvm "виртуалка" poweroff.
• Дахин: командаар виртуал машиныг хэт ачаална VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: тушаалаар SBD чөтгөрийг түдгэлзүүлнэ killall -STOP sbd.
• Унтраах: SSH-ээр виртуал машин руу команд илгээдэг systemctl poweroff, систем аятайхан унтрах болно.
• Салгах: сүлжээний тусгаарлалт, тушаал VBoxManage controlvm "виртуалка" setlinkstate1 off.

"kill-window" стандарт tmux командыг ашиглан туршилтыг дуусгаж байна. Ctrl-b &, эсвэл "үйлчлүүлэгч салгах" команд Ctrl-b d: энэ үед туршилт дуусч, tmux хаагдаж, виртуал машинууд унтарна.

Туршилтын явцад илэрсэн асуудлууд

• Одоогийн байдлаар хоточ нохой чөтгөр sbd нь ажиглагдсан чөтгөрийг зогсоох тал дээр ажилладаг боловч хөлдөөхгүй. Үүний үр дүнд зөвхөн хөлдөхөд хүргэдэг алдаанууд Corosync и Хэм, гэхдээ өлгөөгүй sbd. Шалгах зорилгоор Corosync аль хэдийн PR # 83 (GitHub дээр sbd), сэдэвт хүлээн зөвшөөрөгдсөн мастер. Тэд (PR#83-т) зүрхний аппаратад үүнтэй төстэй зүйл байх болно гэж амласан, би тэгнэ гэж найдаж байна Улаан малгай 8 заавал тэгнэ ээ. Гэхдээ ийм "гажиг" нь таамаглал бөгөөд жишээлбэл, ашиглан зохиомлоор хялбархан дуурайж болно. killall -STOP corosync, гэхдээ бодит амьдрал дээр хэзээ ч уулздаггүй.

• У Хэм зориулсан хувилбарт CentOS 7 буруу тохируулсан sync_timeout у чуулгын төхөөрөмж, үр дүнд нь хэрэв нэг зангилаа бүтэлгүйтсэн бол хоёр дахь зангилаа дахин ачаалагдах магадлалтай, эзэн нь шилжих ёстой байсан. Томруулах замаар эдгэрнэ sync_timeout у чуулгын төхөөрөмж байршуулах явцад (скриптээр setup/setup1). Энэхүү нэмэлт, өөрчлөлтийг хөгжүүлэгчид хүлээж аваагүй Хэм, оронд нь тэд дэд бүтцийг дахин төлөвлөхөөр (тодорхойгүй ирээдүйд) энэ хугацаа автоматаар тооцогдоно гэж амласан.

• Хэрэв мэдээллийн сангийн тохиргоо үүнийг зааж өгсөн бол LC_MESSAGES (текст мессеж) Юникод ашиглаж болно, жишээ нь. ru_RU.UTF-8, дараа нь эхлүүлэх үед Шуудангийн материал Хэмжээ нь UTF-8 биш орчинд, хоосон орчинд (энд Хэм+pgsqlms(paf) гүйдэг Шуудангийн материал), дараа нь лог нь UTF-8 үсгийн оронд асуултын тэмдэг агуулсан байх болно. PostgreSQL хөгжүүлэгчид энэ тохиолдолд юу хийх талаар тохиролцоогүй байна. Энэ нь үнэтэй, та суулгах хэрэгтэй LC_MESSAGES=en_US.UTF-8 өгөгдлийн сангийн жишээг тохируулах (бүтээх) үед.

• Хэрэв wal_receiver_timeout тохируулагдсан бол (анхдагчаар энэ нь 60 секунд), дараа нь tuchanka3 ба tuchanka4 кластерт мастер дээр PostgreSQL-STOP тест хийх үед хуулбарлах нь шинэ мастертай дахин холбогдохгүй. Тэнд хуулбарлах нь синхрон байдаг тул зөвхөн боол зогсохгүй, бас шинэ эзэн зогсдог. PostgreSQL-г тохируулахдаа wal_receiver_timeout=0 тохируулснаар ажиллана.

• Хааяа би ForkBomb тест дээр PostgreSQL дээр хуулбарлах ажиллагаа хөлддөгийг ажигласан (санах ойн ачаалал). ForkBomb-ын дараа заримдаа боолууд шинэ мастертай дахин холбогдохгүй байж болно. Би үүнийг зөвхөн tuchanka3 болон tuchanka4 кластерт тааралдсан бөгөөд мастер нь синхрон хуулбарын улмаас хөлдсөн. Асуудал удаан хугацааны дараа (хоёр цаг орчим) өөрөө алга болсон. Үүнийг засахын тулд илүү их судалгаа хийх шаардлагатай. Шинж тэмдгүүд нь өмнөх алдаатай төстэй бөгөөд энэ нь өөр шалтгаанаас үүдэлтэй боловч ижил үр дагавартай байдаг.

Кроганы зургийг авсан Deviant Урлаг зохиогчийн зөвшөөрөлтэйгээр:

Эх сурвалж: www.habr.com