HAProxy और Keepalived का उपयोग करके PostgreSQL लोड संतुलन

आपके डेटाबेस स्तर की उपलब्धता बढ़ाने में एक प्रॉक्सी परत काफी उपयोगी हो सकती है। यह डेटाबेस विफलताओं और प्रतिकृति टोपोलॉजी परिवर्तनों को संभालने के लिए एप्लिकेशन पक्ष पर कोड की मात्रा को कम कर सकता है। इस ब्लॉग पोस्ट में हम चर्चा करेंगे कि PostgreSQL के शीर्ष पर काम करने के लिए HAProxy कैसे सेटअप करें।

सबसे पहले चीज़ें - HAProxy डेटाबेस के साथ नेटवर्क लेयर प्रॉक्सी के रूप में काम करता है। अंतर्निहित, कभी-कभी जटिल, टोपोलॉजी की कोई समझ नहीं होती है। सभी HAProxy परिभाषित बैकएंड को राउंड-रॉबिन फैशन में पैकेट भेजना है। यह पैकेट का निरीक्षण नहीं करता है और न ही यह प्रोटोकॉल को समझता है जिसमें एप्लिकेशन PostgreSQL के साथ बात करते हैं। नतीजतन, HAProxy के पास एक ही पोर्ट पर रीड/राइट स्प्लिट को लागू करने का कोई तरीका नहीं है - इसके लिए प्रश्नों को पार्स करने की आवश्यकता होगी। जब तक आपका एप्लिकेशन राइट्स से रीड्स को विभाजित कर सकता है और उन्हें अलग-अलग आईपी या पोर्ट पर भेज सकता है, आप दो बैकएंड का उपयोग करके आर/डब्ल्यू स्प्लिट को लागू कर सकते हैं। आइए देखें कि यह कैसे किया जा सकता है।

HAProxy कॉन्फ़िगरेशन

नीचे आप HAProxy में कॉन्फ़िगर किए गए दो PostgreSQL बैकएंड का उदाहरण पा सकते हैं।

listen  haproxy_10.0.0.101_3307_rw
        bind *:3307
        mode tcp
        timeout client  10800s
        timeout server  10800s
        tcp-check expect string master\ is\ running
        balance leastconn
        option tcp-check
        option allbackups
        default-server port 9201 inter 2s downinter 5s rise 3 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100
        server 10.0.0.101 10.0.0.101:5432 check
        server 10.0.0.102 10.0.0.102:5432 check
        server 10.0.0.103 10.0.0.103:5432 check


listen  haproxy_10.0.0.101_3308_ro
        bind *:3308
        mode tcp
        timeout client  10800s
        timeout server  10800s
        tcp-check expect string is\ running.
        balance leastconn
        option tcp-check
        option allbackups
        default-server port 9201 inter 2s downinter 5s rise 3 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100
        server 10.0.0.101 10.0.0.101:5432 check
        server 10.0.0.102 10.0.0.102:5432 check
        server 10.0.0.103 10.0.0.103:5432 check

जैसा कि हम देख सकते हैं, वे लिखने के लिए 3307 और पढ़ने के लिए 3308 पोर्ट का उपयोग करते हैं। इस सेटअप में तीन सर्वर हैं - एक सक्रिय और दो स्टैंडबाय प्रतिकृतियां। क्या महत्वपूर्ण है, नोड्स के स्वास्थ्य को ट्रैक करने के लिए tcp-check का उपयोग किया जाता है। HAProxy पोर्ट 9201 से कनेक्ट होगा और यह एक स्ट्रिंग को वापस देखने की अपेक्षा करता है। बैकएंड के स्वस्थ सदस्य अपेक्षित सामग्री लौटाएंगे, जो स्ट्रिंग वापस नहीं करेंगे उन्हें अनुपलब्ध के रूप में चिह्नित किया जाएगा।

Xinetd सेटअप

जैसा कि HAProxy पोर्ट 9201 की जाँच करता है, इस पर कुछ सुनना होता है। हम वहां सुनने के लिए xinetd का उपयोग कर सकते हैं और हमारे लिए कुछ स्क्रिप्ट चला सकते हैं। ऐसी सेवा का उदाहरण विन्यास इस तरह दिख सकता है:

# default: on
# description: postgreschk
service postgreschk
{
        flags           = REUSE
        socket_type     = stream
        port            = 9201
        wait            = no
        user            = root
        server          = /usr/local/sbin/postgreschk
        log_on_failure  += USERID
        disable         = no
        #only_from       = 0.0.0.0/0
        only_from       = 0.0.0.0/0
        per_source      = UNLIMITED
}

आपको यह सुनिश्चित करने की ज़रूरत है कि आप लाइन जोड़ते हैं:

postgreschk        9201/tcp

/etc/सेवाओं के लिए।

Xinetd एक पोस्टग्रेस्क स्क्रिप्ट शुरू करता है, जिसमें नीचे की तरह सामग्री है:

#!/bin/bash
#
# This script checks if a PostgreSQL server is healthy running on localhost. It will
# return:
# "HTTP/1.x 200 OK\r" (if postgres is running smoothly)
# - OR -
# "HTTP/1.x 500 Internal Server Error\r" (else)
#
# The purpose of this script is make haproxy capable of monitoring PostgreSQL properly
#

export PGHOST='10.0.0.101'
export PGUSER='someuser'
export PGPASSWORD='somepassword'
export PGPORT='5432'
export PGDATABASE='postgres'
export PGCONNECT_TIMEOUT=10

FORCE_FAIL="/dev/shm/proxyoff"

SLAVE_CHECK="SELECT pg_is_in_recovery()"
WRITABLE_CHECK="SHOW transaction_read_only"

return_ok()
{
    echo -e "HTTP/1.1 200 OK\r\n"
    echo -e "Content-Type: text/html\r\n"
    if [ "$1x" == "masterx" ]; then
        echo -e "Content-Length: 56\r\n"
        echo -e "\r\n"
        echo -e "<html><body>PostgreSQL master is running.</body></html>\r\n"
    elif [ "$1x" == "slavex" ]; then
        echo -e "Content-Length: 55\r\n"
        echo -e "\r\n"
        echo -e "<html><body>PostgreSQL slave is running.</body></html>\r\n"
    else
        echo -e "Content-Length: 49\r\n"
        echo -e "\r\n"
        echo -e "<html><body>PostgreSQL is running.</body></html>\r\n"
    fi
    echo -e "\r\n"

    unset PGUSER
    unset PGPASSWORD
    exit 0
}

return_fail()
{
    echo -e "HTTP/1.1 503 Service Unavailable\r\n"
    echo -e "Content-Type: text/html\r\n"
    echo -e "Content-Length: 48\r\n"
    echo -e "\r\n"
    echo -e "<html><body>PostgreSQL is *down*.</body></html>\r\n"
    echo -e "\r\n"

    unset PGUSER
    unset PGPASSWORD
    exit 1
}

if [ -f "$FORCE_FAIL" ]; then
    return_fail;
fi

# check if in recovery mode (that means it is a 'slave')
SLAVE=$(psql -qt -c "$SLAVE_CHECK" 2>/dev/null)
if [ $? -ne 0 ]; then
    return_fail;
elif echo $SLAVE | egrep -i "(t|true|on|1)" 2>/dev/null >/dev/null; then
    return_ok "slave"
fi

# check if writable (then we consider it as a 'master')
READONLY=$(psql -qt -c "$WRITABLE_CHECK" 2>/dev/null)
if [ $? -ne 0 ]; then
    return_fail;
elif echo $READONLY | egrep -i "(f|false|off|0)" 2>/dev/null >/dev/null; then
    return_ok "master"
fi

return_ok "none";

स्क्रिप्ट का तर्क इस प्रकार है। दो प्रश्न हैं जिनका उपयोग नोड की स्थिति का पता लगाने के लिए किया जाता है।

SLAVE_CHECK="SELECT pg_is_in_recovery()"
WRITABLE_CHECK="SHOW transaction_read_only"

यदि PostgreSQL पुनर्प्राप्ति में है तो पहली जाँच - यह सक्रिय सर्वर के लिए 'गलत' और स्टैंडबाय सर्वर के लिए 'सत्य' होगा। दूसरा चेक करता है कि PostgreSQL रीड-ओनली मोड में है या नहीं। सक्रिय सर्वर 'बंद' हो जाएगा जबकि स्टैंडबाय सर्वर 'चालू' वापस आ जाएगा। परिणामों के आधार पर, स्क्रिप्ट रिटर्न_ओके () फ़ंक्शन को एक सही पैरामीटर ('मास्टर' या 'स्लेव' के साथ कॉल करती है, जो पता चला था उसके आधार पर)। यदि प्रश्न विफल हो जाते हैं, तो एक 'रिटर्न_फेल' फ़ंक्शन निष्पादित किया जाएगा।

Return_ok फ़ंक्शन उस तर्क के आधार पर एक स्ट्रिंग देता है जो इसे पारित किया गया था। यदि होस्ट एक सक्रिय सर्वर है, तो स्क्रिप्ट "PostgreSQL मास्टर चल रहा है" वापस आ जाएगी। यदि यह एक स्टैंडबाय है, तो लौटाई गई स्ट्रिंग होगी:"PostgreSQL गुलाम चल रहा है"। यदि स्थिति स्पष्ट नहीं है, तो यह वापस आ जाएगी:"PostgreSQL चल रहा है"। यहीं पर लूप समाप्त होता है। HAProxy xinetd से जुड़कर राज्य की जाँच करता है। बाद वाला एक स्क्रिप्ट शुरू करता है, जो तब एक स्ट्रिंग लौटाता है जिसे HAProxy पार्स करता है।

जैसा कि आपको याद होगा, HAProxy निम्नलिखित स्ट्रिंग्स की अपेक्षा करता है:

tcp-check expect string master\ is\ running

बैकएंड लिखने के लिए और

tcp-check expect string is\ running.

केवल-पढ़ने के लिए बैकएंड के लिए। यह सक्रिय सर्वर को राइट बैकएंड में उपलब्ध एकमात्र होस्ट बनाता है जबकि रीड बैकएंड पर सक्रिय और स्टैंडबाय सर्वर दोनों का उपयोग किया जा सकता है।

ClusterControl में PostgreSQL और HAProxy

ऊपर दिया गया सेटअप जटिल नहीं है, लेकिन इसे सेट करने में कुछ समय लगता है। यह सब आपके लिए सेट करने के लिए ClusterControl का उपयोग किया जा सकता है।

क्लस्टर जॉब ड्रॉपडाउन मेनू में, आपके पास लोड बैलेंसर जोड़ने का विकल्प होता है। फिर HAProxy को परिनियोजित करने का विकल्प दिखाई देता है। आपको यह भरना होगा कि आप इसे कहाँ स्थापित करना चाहते हैं, और कुछ निर्णय लें:उन रिपॉजिटरी से जिन्हें आपने होस्ट पर कॉन्फ़िगर किया है या स्रोत कोड से संकलित नवीनतम संस्करण। आपको यह भी कॉन्फ़िगर करने की आवश्यकता होगी कि आप क्लस्टर में कौन से नोड्स को HAProxy में जोड़ना चाहते हैं।

एक बार HAProxy इंस्टेंस तैनात हो जाने के बाद, आप "नोड्स" टैब में कुछ आंकड़ों तक पहुंच सकते हैं:

जैसा कि हम देख सकते हैं, R/W बैकएंड के लिए, केवल एक होस्ट (सक्रिय सर्वर) को अप के रूप में चिह्नित किया गया है। केवल-पढ़ने के लिए बैकएंड के लिए, सभी नोड्स तैयार हैं।

रखा गया

HAProxy आपके एप्लिकेशन और डेटाबेस इंस्टेंस के बीच बैठेगा, इसलिए यह एक केंद्रीय भूमिका निभाएगा। दुर्भाग्य से यह विफलता का एकल बिंदु भी बन सकता है, यदि यह विफल हो जाता है, तो डेटाबेस के लिए कोई मार्ग नहीं होगा। ऐसी स्थिति से बचने के लिए, आप कई HAProxy इंस्टेंसेस को परिनियोजित कर सकते हैं। लेकिन फिर सवाल यह है कि - कैसे तय किया जाए कि किस प्रॉक्सी होस्ट से जुड़ना है। यदि आपने ClusterControl से HAProxy को परिनियोजित किया है, तो यह एक और "लोड बैलेंसर जोड़ें" कार्य चलाने जितना आसान है, इस बार Keepalived को परिनियोजित करना।

जैसा कि हम ऊपर स्क्रीनशॉट में देख सकते हैं, आप अधिकतम तीन HAProxy होस्ट चुन सकते हैं और उनके राज्य की निगरानी के लिए Keepalived को उनके ऊपर तैनात किया जाएगा। उनमें से एक को एक वर्चुअल आईपी (वीआईपी) सौंपा जाएगा। डेटाबेस से कनेक्ट करने के लिए आपके एप्लिकेशन को इस VIP का उपयोग करना चाहिए। यदि "सक्रिय" HAProxy अनुपलब्ध हो जाएगा, तो VIP को दूसरे होस्ट में ले जाया जाएगा।

जैसा कि हमने देखा है, PostgreSQL के लिए पूर्ण उच्च उपलब्धता स्टैक को तैनात करना काफी आसान है। इसे आज़माएं और अगर आपके पास कोई प्रतिक्रिया है तो हमें बताएं।