होम/ब्लॉग/हार्डवेयर और संचालन
7 मिनट पढ़ने का समय

अपना सर्वर बनाएँ: पुर्ज़ों की सूची से भरोसेमंद संचालन वाले सिस्टम तक

उपयुक्त CPU, ECC RAM, SSD, बिजली आपूर्ति और कूलिंग चुनें। क्षमता उदाहरण, संगतता जाँच और उत्पादन उपयोग से पहले ठोस स्वीकृति प्रक्रिया के साथ।

अच्छा स्वयं-निर्माण पुनर्प्राप्ति से शुरू होकर दर्ज स्वीकृति पर समाप्त होता है। संगत पार्ट जरूरी हैं; स्पेयर योजना, परीक्षण और स्पष्ट संचालन जिम्मेदारी उन्हें सर्वर बनाते हैं।

फ़ाइल सेवा, आंतरिक ऐप या संभालने योग्य वर्चुअलाइज़ेशन के लिए अपना हार्डवेयर सोच रही छोटी IT टीमों और तकनीकी जिम्मेदारी वाले व्यवसायों के लिए।

स्वयं बनाया सिस्टम संचालन में कब ठीक बैठता है

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

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

सार्वभौमिक खरीद सूची के बजाय आवश्यकता प्रोफ़ाइल

काल्पनिक व्यवसाय को फ़ाइल सेवा, छोटा आंतरिक ऐप और कुछ VM चाहिए। पहले वर्ष 1.5 TB उत्पादन डेटा और हर वर्ष 300 GB वृद्धि की योजना है। सेवा सहमत रखरखाव समय में रीस्टार्ट हो सकती है। हार्डवेयर विफलता का अलग पुनर्प्राप्ति लक्ष्य तय है। ये किसी सॉफ़्टवेयर की न्यूनतम शर्तें नहीं।

तकनीकी लक्ष्य विवरण का उदाहरण
क्षेत्रयोजना निर्णयऑर्डर से पहले आवश्यक प्रमाण
CPUऐप और समानांतर उपयोग के आधार पर प्रदर्शनसॉफ़्टवेयर स्वीकृति, वर्चुअलाइज़ेशन और संगत फ़र्मवेयर
RAMजाँचा जाने वाला शुरुआती 64 GBमापी जरूरत और लिखित विस्तार रास्ता
डेटा स्टोरेजअतिरिक्त क्षमता वाला मिररउपयोग योग्य आकार, लिखने का भार और प्रतिस्थापन प्रक्रिया
बूट मीडियाचुने प्लेटफ़ॉर्म के अनुकूलसमर्थित मीडिया और कॉन्फ़िगरेशन पुनर्निर्माण
नेटवर्कसाथ के फ़ाइल और बैकअप भार पर आधारितस्विच, केबल और क्लाइंट में शुरू से अंत तक समर्थन
संचालननिगरानी, UPS और दूसरे स्थान का बैकअपअलर्ट जिम्मेदारी, शटडाउन और बहाली परीक्षण

शुरुआती 1.5 TB और चार वार्षिक 0.3 TB बढ़ोतरी से पाँचवें वर्ष के अंत में 2.7 TB होते हैं। स्वयं चुने 75 प्रतिशत अधिकतम उपयोग लक्ष्य में कम से कम 2.7 / 0.75 = 3.6 TB उपयोग योग्य क्षमता चाहिए। नाममात्र 4 TB की दो ड्राइव का मिरर फ़ाइल सिस्टम खर्च से पहले लगभग 4 TB देता है, 8 TB नहीं। स्नैपशॉट, मेटाडेटा और अस्थायी डेटा भी बजट में हों।

पूरी प्रणाली के लिए CPU और मदरबोर्ड चुनें

अधिक कोर तभी मदद करते हैं जब ऐप समानांतर काम करे। गणना-प्रधान एक कार्य को एक कोर की क्षमता अधिक लाभ दे सकती है। यह भी देखें कि सॉफ़्टवेयर कोर संख्या या दूसरे माप से लाइसेंस होता है और विक्रेता कौन-से प्लेटफ़ॉर्म मंजूर करता है। सस्ता प्रोसेसर आगे की लागत या संगतता कमी से आकर्षण खो सकता है।

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

दूरस्थ प्रबंधन साइट यात्रा बचा सकता है, लेकिन उसकी अपनी पहुँच और अपडेट योजना चाहिए। वह केवल निर्धारित सुरक्षित प्रबंधन वातावरण से उपलब्ध हो। पहुँच, स्थानापन्न और पुनर्प्राप्ति सुरक्षित दर्ज करें। रीस्टार्ट के बाद डिस्प्ले बिना कोई न चला सके तो घटना में सिस्टम अनावश्यक कठिन है।

खरीद से पहले ECC और मॉड्यूल व्यवस्था पक्की करें

ECC के लिए केवल वैसा लेबल वाला मेमोरी मॉड्यूल पर्याप्त नहीं। Intel प्रोसेसर और चिपसेट समर्थन को पूर्व-आवश्यकता बताता है। विशिष्ट प्लेटफ़ॉर्म की स्वीकृति और मदरबोर्ड मेमोरी सूची देखें; DIMM प्रकार और व्यवस्था मेल खाएँ। स्थापना के बाद क्षमता और त्रुटि सुधार वास्तव में पहचाने गए हैं या नहीं जाँचें। Intel: ECC समर्थन जाँचें ↗

मेमोरी चैनल और बाद का विस्तार साथ नियोजित करें। अगले चरण में हर मॉड्यूल बदलने वाली शुरुआत जीवनकाल में महँगी हो सकती है। उलटे खाली स्लॉट रखने के लिए बिना जाँच जरूरी बैंडविड्थ न घटाएँ। मैनुअल और ऐप के भार से निर्णय समर्थित करें।

SSD को लिखने के भार और दैनिक व्यवहार पर परखें

अधिकतम अनुक्रमिक ट्रांसफ़र दर नहीं बताती कि SSD कई छोटे लेखन या लगातार भार के बाद कितनी जल्दी उत्तर देती है। डेटाबेस और VM में मिश्रित भार प्रतिक्रिया समय, लेखन सहनशीलता और बिजली जाने का व्यवहार महत्वपूर्ण है। Kingston डेटा सेंटर SSD के लिए ये गुण अलग देता है। सही मॉडल और क्षमता के विनिर्देश देखें। Kingston: डेटा सेंटर SSD के गुण ↗

हमारी योजना गणना में रोज़ 300 GB तार्किक लेखन, 365 दिन के पाँच वर्षों में लगभग 547.5 TB है। यह ड्राइव विनिर्देश जाँचने की शुरुआत है, जीवनकाल भविष्यवाणी नहीं। आंतरिक राइट एम्प्लिफ़िकेशन, भार प्रकार और वारंटी भी देखें। अधिक TBW न हर खराबी से सुरक्षा, न निश्चित बहाली समय का वादा है।

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

सॉफ़्टवेयर, कूलिंग और स्थान साथ नियोजित करें

ऑर्डर से पहले संचालन प्लेटफ़ॉर्म चुनें। स्टोरेज ऑपरेटिंग सिस्टम के बूट मीडिया और कंट्रोलर नियम वर्चुअलाइज़ेशन होस्ट से अलग हो सकते हैं। उदाहरणतः TrueNAS हार्डवेयर गाइड मेमोरी, बूट डिवाइस और ड्राइव कनेक्शन की अलग आवश्यकताएँ और सलाह देता है। ऐसा दस्तावेज़ चुने प्लेटफ़ॉर्म की सूची है; न्यूनतम संख्या आपकी भार योजना का विकल्प नहीं। TrueNAS: हार्डवेयर गाइड ↗

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

पावर सप्लाई और UPS इच्छित कॉन्फ़िगरेशन तथा मापे भार से तय करें। UPS निश्चित समय संभाले या नियंत्रित बंद करना दे। वह एक साइट को दो नहीं बनाता। बिजली जाने से बाद के रीस्टार्ट तक क्रम बनाएँ और सुरक्षित रखरखाव समय में जाँचें; विद्युत स्थापना योग्य लोगों का काम है।

उत्पादन डेटा से पहले: दर्ज स्वीकृति

  1. सूची बनाएँ: पार्ट, सीरियल नंबर, फ़र्मवेयर संस्करण, वारंटी और आपूर्तिकर्ता लिखें।
  2. संगतता देखें: पहचानी क्षमता, मेमोरी व्यवस्था और जरूरी ड्राइव तथा इंटरफ़ेस जाँचें।
  3. हार्डवेयर जाँचें: मेमोरी निदान और लंबा प्रतिनिधि भार चलाकर तापमान तथा त्रुटि संदेश देखें।
  4. ऐप जाँचें: साथ उपयोगकर्ता, आयात, रिपोर्ट और बैकअप को सहमत प्रतिक्रिया समय से परखें।
  5. रीस्टार्ट स्वीकार करें: नियोजित रीस्टार्ट बाद सेवाएँ, निर्भरताएँ और निगरानी देखें।
  6. बहाली अभ्यास करें: बैकअप से अलग परीक्षण वातावरण बनाएँ और कारोबारी उपयोगकर्ताओं से ऐप मंजूर कराएँ।
  7. संचालन सौंपें: जिम्मेदार लोग, स्पेयर मार्ग, अलर्ट संपर्क और रखरखाव समय लिखित पक्का करें।

सफल स्वीकृति में परिणाम और विचलन हों, सिर्फ टिक नहीं। बैकअप योजना से लंबा हो तो लॉन्च से पहले तय करें कि नेटवर्क, ड्राइव या प्रतिधारण बदलना है। हार्डवेयर खराबी अस्पष्ट रहे तो उत्पादन अभी शुरू न करें। इससे भावी टीम ऐसी मशीन से बचती है जिसकी ज्ञात कमजोरी केवल मौखिक मिली हो।

पहली योजना में दूसरा निर्माण भी रखें

लिखें कि ऐप दूसरे हार्डवेयर पर फिर कैसे स्थापित होगा। स्थापना मीडिया, कॉन्फ़िगरेशन, जरूरी पहुँच और बैकअप खराब डिवाइस से स्वतंत्र उपलब्ध हों। समान मॉडल वाला मदरबोर्ड हमेशा जल्दी नहीं मिलता। इसलिए बहाली उस एक भाग पर यथासंभव कम निर्भर हो।

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

संबंधित पेशकश

Bissolux आपकी कैसे मदद कर सकता है

इस मार्गदर्शन को एक व्यावहारिक कदम में बदलें। ऑर्डर देने से पहले सेवा का दायरा, कीमत और शामिल न होने वाली मदें जाँच लें।

संबंधित पेशकश: आईटी बुनियादी ढाँचाविज्ञापन · Bissolux
सेवा का सांकेतिक चित्र
Bissolux · हमारी पेशकशआईटी बुनियादी ढाँचा

आईटी बुनियादी ढाँचा

अपने सिस्टम और ज़रूरतों के बारे में बताएँ। काम शुरू करने से पहले हम उसका दायरा, ज़िम्मेदारियाँ और शर्तें तय करेंगे। संपर्क पेज अंग्रेज़ी में उपलब्ध है।

संबंधित पेशकश: आईटी सहायता और संचालनविज्ञापन · Bissolux
सेवा का सांकेतिक चित्र
Bissolux · हमारी पेशकशआईटी सहायता और संचालन

आईटी सहायता और संचालन

अपने सिस्टम और ज़रूरतों के बारे में बताएँ। काम शुरू करने से पहले हम उसका दायरा, ज़िम्मेदारियाँ और शर्तें तय करेंगे। संपर्क पेज अंग्रेज़ी में उपलब्ध है।