HAProxy առողջության ստուգումներ Squid փոխանցող պրոքսիի համար

Պրոքսի հոսթի վրա /check.txt անունով ֆայլը թվում է ակնհայտ առողջության թիրախ։ Խնդիրն այն է, որ Squid-ի բացահայտ փոխանցող լսողը սովորական կայք չէ, որը սպասարկում է այդ հոսթի փաստաթղթերի արմատը։

Բնօրինակի ոճով հարցումը, ինչպիսին HEAD /check.txt HTTP/1.1-ն է, բաց է թողնում փոխանցող պրոքսիով սովորական HTTP հարցման համար սպասվող բացարձակ թիրախը։ Կախված կարգավորումից՝ այն կարող է մերժվել կամ մշակվել մեկ այլ տեղական ծառայության կողմից։ Երկու արդյունքներն էլ կարող են ավելի քիչ ասել, քան հուշում է վահանակը։

Ընտրեք այն ծառայությունը, որը պետք է հասանելի մնա

Երրորդ դեպքում հարցմանը թիրախ է պետք, օրինակ՝

HEAD http://probe.example.internal/proxy-ready HTTP/1.1
Host: probe.example.internal

Հոսթի անունը միայն օրինակ է։ Օգտագործեք վերահսկվող վերջնակետ, որը պրոքսը կարող է լուծել և որին նրան դիտավորյալ թույլատրված է հասնել։ HAProxy-ի http-check send-ը աջակցում է մեթոդի, URI-ի, տարբերակի և վերնագրերի ընտրությանը. կարգավորեք այդ հարցումը բացահայտորեն՝ փոխարենը չժառանգելով բնօրինակ սերվերի օրինակն անփոփոխ։

HEAD-ը կարող է ստուգել պատասխանի կարգավիճակը և վերնագրերը։ Այն չի կարող վավերացնել պատասխանի մարմինը, որը երբեք չի փոխանցվում։ Եթե առողջության պայմանագիրը պահանջում է մարմնի նշիչ, ընտրեք համապատասխան GET ստուգում և վավերացրեք այդ նշիչը։

Երբ պրոքսի նույնականացում կա, պահեք ստուգման հաշիվը և աղբյուրի սահմանափակումները նեղ։ Ամբողջ լսողին նույնականացումից ազատելը կանաչ նշանի համար փոխում է այն ծառայությունը, որը պաշտպանվում է։

Վերջապես, որոշեք, թե ինչ պետք է հեռացնի ձախողված ստուգումը։ Վերահսկվող բնօրինակի խափանումը կարող է միաժամանակ ձախողել յուրաքանչյուր պրոքսի փոխանցման ստուգումը։ Դա կարող է լինել հենց այն կախվածությունը, որը ցանկանում եք չափել, կամ պատճառ՝ լսողի առողջությունն ու ծայրից ծայր հասանելիությունը պահել որպես առանձին ազդանշաններ։