उत्पादन के लिए एक MySQL या MariaDB सर्वर तैयार करना - भाग एक

लंबे समय में संचालन को सुचारू करने के लिए आवश्यक पैकेजों और उपकरणों के साथ एक उत्पादन MySQL सर्वर को स्थापित और कॉन्फ़िगर करना अत्यंत महत्वपूर्ण है। हमने ऐसे कई मामले देखे हैं जहां समस्या की पहचान करने और समस्या को हल करने में मदद करने के लिए सर्वर पर स्थापित आवश्यक उपकरणों की कमी के कारण उत्पादन सर्वर (विशेष रूप से सार्वजनिक इंटरनेट एक्सेस के बिना) का समस्या निवारण या ट्यूनिंग आमतौर पर मुश्किल होता है।

इस दो-भाग वाली ब्लॉग श्रृंखला में, हम आपको सिस्टम व्यवस्थापक के दृष्टिकोण से उत्पादन उपयोग के लिए MySQL सर्वर तैयार करने के 9 टिप्स और ट्रिक्स दिखाने जा रहे हैं। इस ब्लॉग पोस्ट के सभी उदाहरण हमारे दो-नोड, मास्टर-स्लेव MySQL प्रतिकृति सेटअप पर आधारित हैं जो CentOS 7 पर चल रहा है।

आवश्यक पैकेज स्थापित करें

MySQL या MariaDB क्लाइंट और सर्वर पैकेज की स्थापना के बाद, हमें MySQL/MariaDB सर्वर को सभी आवश्यक उपकरणों के साथ तैयार करने की आवश्यकता है ताकि सभी प्रशासन, प्रबंधन और निगरानी कार्यों का सामना किया जा सके। सर्वर। यदि आप उत्पादन में MySQL सर्वर को बंद करने की योजना बना रहे हैं, तो इंटरनेट कनेक्शन के बिना उन सभी को मैन्युअल रूप से स्थापित करना थोड़ा कठिन होगा।

कुछ महत्वपूर्ण पैकेज जिन्हें Linux के लिए MySQL/MariaDB सर्वर पर संस्थापित किया जाना चाहिए:

• Percona Xtrabackup/MariaDB बैकअप - डेटाबेस सर्वर का नॉन-ब्लॉकिंग फिजिकल बैकअप।
• ntp/ntpdate - सर्वर का समय सिंक करें।
• pv - एक पाइपलाइन के माध्यम से डेटा की निगरानी करें, थ्रॉटलिंग के लिए भी इस्तेमाल किया जा सकता है।
• सोसाइट या नेटकैट- डेटा स्ट्रीमिंग टूल, स्ट्रीमिंग बैकअप के लिए अच्छा है।
• नेट-टूल्स - Linux के लिए नेटवर्क डिबगिंग टूल का एक संग्रह।
• बाइंड-यूटिल्स - Linux के लिए DNS डिबगिंग टूल का एक संग्रह।
• sysstat - Linux के लिए प्रदर्शन निगरानी उपकरणों का एक संग्रह।
• टेलनेट - टेलनेट क्लाइंट सेवा की पुन:उपलब्धता की जांच करने के लिए।
• mailx/mailutils - MTA क्लाइंट।
• openssl - ट्रांसपोर्ट लेयर सिक्योरिटी (TLS) और सिक्योर सॉकेट लेयर (SSL) प्रोटोकॉल के लिए टूलकिट।
• अनज़िप - टूल को अनकंप्रेस करें।
• htop - होस्ट मॉनिटरिंग टूल।
• innotop - MySQL मॉनिटरिंग टूल।
• vim - सिंटैक्स हाइलाइटिंग वाला टेक्स्ट एडिटर (या कोई पसंदीदा टेक्स्ट एडिटर)।
• पायथन-सेटअपटूल - पायथन पैकेज मैनेजर।
• lm_sensors/ipmitool - सर्वर घटक के तापमान की जांच करने के लिए। केवल बेयर-मेटल सर्वर।

ध्यान दें कि कुछ सुझाए गए पैकेज केवल गैर-डिफ़ॉल्ट पैकेज रिपॉजिटरी जैसे EPEL for CentOS में उपलब्ध हैं। इसलिए, YUM-आधारित स्थापना के लिए:

$ yum install epel-release
$ yum install -y wget ntp pv socat htop innotop vim mailx bind-utils net-tools telnet sysstat openssl python-setuptools lm_sensors ipmitool

APT-आधारित स्थापना के लिए:

$ apt-get install ntp pv socat htop innotop vim easy_install mailutils bind-utils sysstat net-tools telnet openssl lm_sensors ipmitool

MySQL कमांड लाइन इंटरफेस के लिए, हम मानक "mysql" कमांड लाइन क्लाइंट के अलावा अन्य टूल का उपयोग कर सकते हैं, जैसे कि mycli, ऑटो-पूर्णता और सिंटैक्स हाइलाइटिंग के साथ। पैकेज को स्थापित करने के लिए, हम पाइप (पायथन पैकेज मैनेजर) का उपयोग कर सकते हैं:

$ pip install mycli

mycli के साथ, उत्पादन सर्वर के साथ व्यवहार करते समय मानव-त्रुटि वेक्टर को बेहतर विज़ुअलाइज़ेशन के साथ कम किया जा सकता है, जैसा कि निम्न स्क्रीनशॉट में दिखाया गया है:

सार्थक शेल प्रॉम्प्ट

यह हिस्सा पहली जगह में अनावश्यक लगता है, लेकिन शायद यह आपको उत्पादन में मूर्खतापूर्ण गलतियों से बचाने वाला है। एक इंसान के रूप में, हम विशेष रूप से एक तीव्र क्षण के दौरान विनाशकारी आदेश चलाते समय त्रुटियां करने के लिए प्रवण होते हैं, उदाहरण के लिए जब उत्पादन सर्वर डाउन होता है।

निम्न स्क्रीनशॉट पर एक नज़र डालें। डिफ़ॉल्ट रूप से, बैश PS1 प्रॉम्प्ट (प्राथमिक प्रॉम्प्ट) बहुत सुस्त दिखता है:

एक अच्छे PS1 प्रॉम्प्ट को SysAdmins को इसके बारे में अधिक जागरूक बनाने के लिए विशिष्ट जानकारी प्रदान करनी चाहिए। पर्यावरण, सर्वर और वर्तमान पथ जिससे वे वर्तमान में निपट रहे हैं। परिणामस्वरूप, व्यक्ति अधिक सावधान रहेगा और हमेशा यह जान पाएगा कि कमांड निष्पादित करने के लिए वह सही पथ/सर्वर/उपयोगकर्ता में है या नहीं।

इसे प्राप्त करने के लिए, PS1 (प्राथमिक प्रॉम्प्ट) कॉन्फ़िगरेशन का वर्णन करने वाली रेखा खोजें, आमतौर पर /etc/bashrc लाइन 41 में:

  [ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\[email protected]\h \W]\\$ "

और इसे इस लाइन से बदलें:

  [ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\[\e[36m\]\u\[\e[m\]@\[\e[32m\]\h\[\e[m\]\[\e[31;47m\]Production\[\e[m\]: \[\e[33m\]\w\[\e[m\]]$ "

टर्मिनल से लॉग आउट करें और फिर से लॉगिन करें। अब आपको टर्मिनल में कुछ इस तरह दिखना चाहिए:

जैसा कि ऊपर स्क्रीनशॉट में दिखाया गया है, वर्तमान उपयोगकर्ता (नीला), सर्वर का होस्टनाम (हरा), प्रोडक्शन टियर (सफेद पृष्ठभूमि के साथ लाल रंग में बोल्ड), वर्तमान निर्देशिका (पीला) के पूर्ण पथ के साथ वर्तमान सत्र का एक बेहतर सारांश प्रदान करता है जहां महत्वपूर्ण जानकारी अलग-अलग रंगों से आसानी से अलग हो जाती है।

आप अपने बैश प्रॉम्प्ट को अपने स्वाद के अनुरूप अनुकूलित करने के लिए इस मुफ्त ऑनलाइन टूल का उपयोग कर सकते हैं।

MOTD

यदि आप MySQL या MariaDB प्रतिकृति जैसी कई भूमिकाओं के साथ एक डेटाबेस क्लस्टर का प्रबंधन कर रहे हैं, तो किसी एक होस्ट को सीधे प्रशासित करते समय हमेशा यह चिंताजनक भावना होना आम है क्योंकि हमें यह सत्यापित करने के लिए अतिरिक्त जाँच करने की आवश्यकता है कि हम जिस नोड में हैं, वह वह है जिसे हम वास्तव में प्रशासित करना चाहते हैं। प्रतिकृति टोपोलॉजी अधिक जटिल हो जाती है क्योंकि आपका डेटाबेस क्लस्टर बड़ा हो जाता है और क्लस्टर में इंटरमीडिएट मास्टर, बिनलॉग सर्वर, सेमी-सिंक प्रतिकृति के साथ बैकअप मास्टर, रीड-ओनली स्लेव और बैकअप सत्यापन सर्वर जैसी कई भूमिकाएँ हो सकती हैं।

यह बेहतर होगा यदि हम डेटाबेस स्थिति का सारांश प्राप्त कर सकें जब भी हम उस विशेष सर्वर में हों, बस हमें यह बताने के लिए कि हम किससे निपटने जा रहे हैं। जब भी हम सर्वर में लॉग इन करते हैं तो हम इस व्यवहार को स्वचालित करने के लिए लिनक्स के संदेश का दिन (एमओटीडी) का उपयोग कर सकते हैं। डिफ़ॉल्ट /etc/motd का उपयोग केवल स्थिर सामग्री के लिए अच्छा है, जो कि हम वास्तव में नहीं चाहते हैं यदि हम एक MySQL सर्वर की वर्तमान स्थिति की रिपोर्ट करना चाहते हैं।

समान परिणाम प्राप्त करने के लिए, हम अपने MySQL/MariaDB सर्वर को संक्षेप में प्रस्तुत करने के लिए एक सार्थक MOTD आउटपुट उत्पन्न करने के लिए एक साधारण बैश स्क्रिप्ट का उपयोग कर सकते हैं, उदाहरण के लिए:

$ vim ~/.motd.sh
#!/bin/bash
# Auto-generate MOTD for MySQL/MariaDB Replication
# .motd.sh, to be executed under ~/.bash_profile

#####
# Preferred role of the node, pick one
#PREFER_ROLE='Slave'
PREFER_ROLE='Master'
#####

HOSTNAME=$(hostname)
UPTIME=$(uptime -p)
MYSQL_COMMAND='mysql --connect-timeout=2 -A -Bse'
MYSQL_READONLY=$(${MYSQL_COMMAND} 'SHOW GLOBAL VARIABLES LIKE "read_only"' | awk {'print $2'})
TIER='Production'
MAIN_IP=$(hostname -I | awk {'print $1'})
CHECK_MYSQL_REPLICATION=$(${MYSQL_COMMAND} 'SHOW SLAVE STATUS\G' | egrep 'Slave_.*_Running: Yes$')
MYSQL_MASTER=$(${MYSQL_COMMAND} 'SHOW SLAVE STATUS\G' | grep Master_Host | awk {'print $2'})
# The following requires show_compatibility_56=1 for MySQL 5.7 and later
MYSQL_UPTIME=$(${MYSQL_COMMAND} 'SELECT TIME_FORMAT(SEC_TO_TIME(VARIABLE_VALUE ),"%Hh %im")  AS Uptime FROM information_schema.GLOBAL_STATUS WHERE VARIABLE_NAME="Uptime"')

# coloring
bold=$(tput bold)
red=$(tput setaf 1)
green=$(tput setaf 2)
normal=$(tput sgr0)

MYSQL_SHOW=1
if [ $MYSQL_READONLY == 'ON' ]; then
        CURRENT_MYSQL_ROLE='Slave'
        if ${MYSQL_COMMAND} 'SHOW SLAVE STATUS\G' | egrep 'Slave_.*_Running: Yes$' &>/dev/null ; then
                lag=$(${MYSQL_COMMAND} 'SHOW SLAVE STATUS\G' | egrep 'Seconds_Behind_Master:' | awk {'print $2'})
                if [ $lag -eq 0 ]; then
                        REPLICATION_STATUS="${green}Healthy  "
                else
                        if [ $lag == 'NULL' ]; then
                                REPLICATION_STATUS=${red}Unhealthy
                        else
                                REPLICATION_STATUS="${red}Lagging ${lag}s"
                        fi
                fi
        else
                REPLICATION_STATUS=${red}Unhealthy
        fi

elif [ $MYSQL_READONLY == 'OFF' ]; then
        CURRENT_MYSQL_ROLE='Master'
        SLAVE_HOSTS=$(${MYSQL_COMMAND} 'SHOW SLAVE HOSTS' | awk {'print $1'})
else
        MYSQL_SHOW=0
fi

if [ $TIER == 'Production' ]; then
        TIER=${green}Production
fi

if [ $PREFER_ROLE == $CURRENT_MYSQL_ROLE ]; then
        MYSQL_ROLE=${green}$CURRENT_MYSQL_ROLE
else
        MYSQL_ROLE=${red}$CURRENT_MYSQL_ROLE
fi

echo
echo "HOST INFO"
echo "========="
echo -e "  Hostname       : ${bold}$HOSTNAME${normal} \t Server Uptime  : ${bold}$UPTIME${normal}"
echo -e "  IP Address       : ${bold}$MAIN_IP${normal} \t Tier           : ${bold}$TIER${normal}"
echo
if [ $MYSQL_SHOW -eq 1 ]; then
        echo "MYSQL STATE"
        echo "==========="
        echo -e "  Current role      : ${bold}$MYSQL_ROLE${normal} \t\t Read-only      : ${bold}$MYSQL_READONLY${normal}"
        echo -e "  Preferred role    : ${bold}$PREFER_ROLE${normal} \t\t DB Uptime      : ${bold}$MYSQL_UPTIME${normal}"
        if [ $CURRENT_MYSQL_ROLE == 'Slave' ]; then
                echo -e "  Replication state : ${bold}$REPLICATION_STATUS${normal} \t Current Master : ${bold}$MYSQL_MASTER${normal}"
        else
                echo -e "  Slave Hosts(s) ID : "
                for i in $SLAVE_HOSTS; do
                        echo -e "      - ${bold}$i${normal} \t"; done
        fi
        echo
fi

पंक्ति 8 या 9 पर MySQL भूमिकाओं में से एक चुनें, या तो एक मास्टर या एक दास और स्क्रिप्ट को सहेजें। इस स्क्रिप्ट को डेटाबेस उपयोगकर्ता क्रेडेंशियल्स को संग्रहीत करने के लिए MySQL विकल्प फ़ाइल की आवश्यकता होती है, इसलिए हमें इसे पहले बनाना होगा:

$ vim ~/.my.cnf

और निम्नलिखित पंक्तियाँ जोड़ें:

[client]
user=root
password='YourRootP4ssw0rd'

पासवर्ड वाले हिस्से को वास्तविक MySQL रूट पासवर्ड से बदलें। फिर, स्क्रिप्ट के लिए निष्पादन योग्य अनुमति लागू करें:

$ chmod 755 ~/.motd.sh

निष्पादन योग्य स्क्रिप्ट का परीक्षण करें कि यह सही आउटपुट देता है या नहीं:

$ ~/.motd.sh

यदि आउटपुट अच्छा दिखता है (कोई त्रुटि या चेतावनी नहीं), तो स्क्रिप्ट को ~/.bash_profile में जोड़ें ताकि जब कोई उपयोगकर्ता लॉग इन करे तो यह स्वचालित रूप से लोड हो जाएगा:

$ whoami
root
$ echo '~/.motd.sh' >> ~/.bash_profile

टर्मिनल को फिर से लॉगिन करें और आपको मास्टर पर कुछ इस तरह दिखाई देना चाहिए:

गुलाम पर रहते हुए, आपको कुछ इस तरह दिखना चाहिए:

ध्यान दें कि यह स्क्रिप्ट विशेष रूप से एक साधारण MySQL/MariaDB वन के लिए लिखी गई है- स्तरीय मास्टर-दास प्रतिकृति। यदि आपके पास अधिक जटिल सेटअप है, तो आपको शायद स्क्रिप्ट को संशोधित करना होगा, या आप अन्य MySQL क्लस्टरिंग तकनीक जैसे गैलेरा क्लस्टर, ग्रुप प्रतिकृति या एनडीबी क्लस्टर का उपयोग करना चाहते हैं। विचार डेटाबेस नोड स्थिति और जानकारी को ठीक उसी समय प्राप्त करना है जब हम लॉग इन करते हैं ताकि हम डेटाबेस सर्वर की वर्तमान स्थिति से अवगत हों जिस पर हम काम कर रहे हैं।

सेंसर और तापमान

इस भाग को आमतौर पर कई SysAdmins द्वारा अनदेखा किया जा रहा है। तापमान की निगरानी करना महत्वपूर्ण है क्योंकि अगर ओवरहीटिंग होने पर सर्वर अप्रत्याशित रूप से व्यवहार करता है तो हम एक बड़ा आश्चर्य नहीं प्राप्त करना चाहते हैं। एक भौतिक सर्वर में आमतौर पर एक बॉक्स में एक साथ चिपके सैकड़ों इलेक्ट्रॉनिक भाग होते हैं और तापमान परिवर्तन के प्रति संवेदनशील होते हैं। एक विफल कूलिंग फैन सीपीयू के तापमान को उसकी हार्ड लिमिट तक बढ़ा सकता है, जो अंततः सीपीयू घड़ी को थ्रॉटल डाउन कर देता है और डेटा प्रोसेसिंग प्रदर्शन को समग्र रूप से प्रभावित करता है।

हम इस उद्देश्य के लिए एलएम-सेंसर पैकेज का उपयोग कर सकते हैं। इसे स्थापित करने के लिए, बस करें:

$ yum install lm-sensors # apt-get install lm-sensors for APT

फिर सेंसर-डिटेक्ट प्रोग्राम को स्वचालित रूप से यह निर्धारित करने के लिए चलाएं कि आपको lm_sensors का सबसे प्रभावी ढंग से उपयोग करने के लिए कौन से कर्नेल मॉड्यूल लोड करने की आवश्यकता है:

$ sensors-detect

सभी प्रश्नों के उत्तर देता है (आमतौर पर केवल सभी सुझाए गए उत्तरों को स्वीकार करें)। कुछ होस्ट जैसे वर्चुअल मशीन या कंटेनर इस मॉड्यूल का समर्थन नहीं करते हैं। सेंसर को वास्तव में मेजबान (नंगे धातु) स्तर पर होना चाहिए। अधिक जानकारी के लिए इस सूची को देखें।

फिर, सेंसर कमांड चलाएँ:

$ sensors
i350bb-pci-0203
Adapter: PCI adapter
loc1:         +53.0°C (high = +120.0°C, crit = +110.0°C)

power_meter-acpi-0
Adapter: ACPI interface
power1:        4.29 MW (interval =   1.00 s)

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +55.0°C (high = +85.0°C, crit = +95.0°C)
Core 0:        +45.0°C (high = +85.0°C, crit = +95.0°C)
Core 1:        +51.0°C (high = +85.0°C, crit = +95.0°C)
Core 2:        +47.0°C (high = +85.0°C, crit = +95.0°C)
Core 3:        +51.0°C (high = +85.0°C, crit = +95.0°C)
Core 4:        +49.0°C (high = +85.0°C, crit = +95.0°C)
Core 5:        +48.0°C (high = +85.0°C, crit = +95.0°C)
Core 8:        +47.0°C (high = +85.0°C, crit = +95.0°C)
Core 9:        +49.0°C (high = +85.0°C, crit = +95.0°C)
Core 10:       +48.0°C (high = +85.0°C, crit = +95.0°C)
Core 11:       +48.0°C (high = +85.0°C, crit = +95.0°C)
Core 12:       +46.0°C (high = +85.0°C, crit = +95.0°C)
Core 13:       +49.0°C (high = +85.0°C, crit = +95.0°C)

coretemp-isa-0001
Adapter: ISA adapter
Package id 1:  +53.0°C (high = +85.0°C, crit = +95.0°C)
Core 0:        +46.0°C (high = +85.0°C, crit = +95.0°C)
Core 1:        +48.0°C (high = +85.0°C, crit = +95.0°C)
Core 2:        +47.0°C (high = +85.0°C, crit = +95.0°C)
Core 3:        +45.0°C (high = +85.0°C, crit = +95.0°C)
Core 4:        +46.0°C (high = +85.0°C, crit = +95.0°C)
Core 5:        +47.0°C (high = +85.0°C, crit = +95.0°C)
Core 8:        +47.0°C (high = +85.0°C, crit = +95.0°C)
Core 9:        +45.0°C (high = +85.0°C, crit = +95.0°C)
Core 10:       +45.0°C (high = +85.0°C, crit = +95.0°C)
Core 11:       +46.0°C (high = +85.0°C, crit = +95.0°C)
Core 12:       +46.0°C (high = +85.0°C, crit = +95.0°C)
Core 13:       +46.0°C (high = +85.0°C, crit = +95.0°C)

उपरोक्त परिणाम सीपीयू के प्रत्येक कोर के साथ समग्र सीपीयू तापमान को दर्शाता है। एक अन्य उपकरण जिसका उपयोग हम सर्वर घटकों की समग्र स्थिति को देखने के लिए कर सकते हैं, वह है ipmitool। स्थापित करने के लिए, बस करें:

$ yum -y install ipmitool

निम्न कमांड चलाकर, हम सर्वर में भौतिक घटकों की समग्र स्थिति बता सकते हैं:

$ ipmitool sdr list full
Inlet_Temp       | 20 degrees C   | ok
PCIe_Inlet_Temp  | 37 degrees C   | ok
Outlet_Temp      | 20 degrees C   | ok
CPU0_VR_Temp     | 39 degrees C   | ok
CPU1_VR_Temp     | 41 degrees C   | ok
CPU0_Temp        | 55 degrees C   | ok
CPU1_Temp        | 52 degrees C   | ok
PCH_Temp         | 58 degrees C   | ok
DIMMG0_Temp      | 35 degrees C   | ok
DIMMG1_Temp      | 32 degrees C   | ok
PSU0_Temp        | 0 degrees C    | ok
PSU1_Temp        | 0 degrees C    | ok
SYS_3.3V         | 3.30 Volts     | ok
SYS_5V           | 5 Volts        | ok
SYS_12V          | 12.10 Volts    | ok
CPU0_VCORE       | 1.79 Volts     | ok
CPU1_VCORE       | 1.79 Volts     | ok
CPU0_DDR_VDD     | 1.23 Volts     | ok
CPU1_DDR_VDD     | 1.23 Volts     | ok
SYS_FAN1_Speed   | 4018 RPM   | ok
SYS_FAN2_Speed   | 4116 RPM   | ok
SYS_FAN3_Speed   | 4116 RPM   | ok
SYS_FAN4_Speed   | 4116 RPM   | ok
SYS_FAN5_Speed   | 4018 RPM   | ok
SYS_FAN6_Speed   | 4116 RPM   | ok
SYS_FAN7_Speed   | 4018 RPM   | ok
SYS_FAN8_Speed   | 4116 RPM   | ok
SYS_FAN9_Speed   | 4018 RPM   | ok
SYS_FAN10_Speed  | 4116 RPM   | ok
SYS_FAN11_Speed  | 4116 RPM   | ok
SYS_FAN12_Speed  | 4116 RPM   | ok
SYS_FAN13_Speed  | 4116 RPM   | ok
SYS_FAN14_Speed  | 4214 RPM   | ok
Airflow_rate     | 16 CFM     | ok
PSU1_PIN         | 0 Watts    | ok
PSU2_PIN         | 0 Watts    | ok
PSU1_POUT        | 0 Watts    | ok
PSU2_POUT        | 0 Watts    | ok
PSU1_IIN         | 0 Amps     | ok
PSU2_IIN         | 0 Amps     | ok
PSU1_VIN         | 0 Volts    | ok
PSU2_VIN         | 0 Volts    | ok
CPU_Power        | 63 Watts   | ok
MEM_Power        | 8 Watts    | ok
Total_Power      | 0 Watts    | ok
BP_Power         | 8 Watts    | ok
FAN_Power        | 6 Watts    | ok
MB_Power         | 0 Watts    | ok

सूची लंबी है लेकिन स्व-व्याख्यात्मक है और आपको समग्र सर्वर घटकों की स्थिति की निगरानी करने में सक्षम होना चाहिए। ऐसे मामले हो सकते हैं जहां कुछ पंखे पूरी गति से नहीं चल रहे हों जो तब सीपीयू के तापमान को बढ़ाते हैं। समस्या को ठीक करने के लिए हार्डवेयर प्रतिस्थापन की आवश्यकता हो सकती है।

ध्यान दें कि इंटेलिजेंट प्लेटफॉर्म मैनेजमेंट इंटरफेस (आईपीएमआई) कर्नेल मॉड्यूल को मदरबोर्ड पर सक्षम होने के लिए बेसबोर्ड मैनेजमेंट कंट्रोलर (बीएमसी) की आवश्यकता होती है। यह उपलब्ध है या नहीं यह सत्यापित करने के लिए dmesg का उपयोग करें:

$ dmesg | grep -i bmc
[    8.063470] ipmi_si IPI0001:00: Found new BMC (man_id: 0x000000, prod_id: 0x02f3, dev_id: 0x20)

अन्यथा, यदि यह नियंत्रक अक्षम है, तो सर्वर की BIOS सेटिंग जांचें।

अभी के लिए बस इतना ही। इस ब्लॉग श्रृंखला के भाग दो में शेष 5 विषयों जैसे बैकअप टूल कॉन्फ़िगरेशन, तनाव परीक्षण और सर्वर लॉक डाउन को शामिल किया जाएगा।