एक मशीन पर डेटा को कैसे स्टोर किया जाए जिसकी शक्ति यादृच्छिक रूप से कट जाती है

Question

मेरे पास एक भौतिक मशीन होस्ट पर चलने वाली एक वर्चुअल मशीन (डेबियन) है। वर्चुअल मशीन डेटा के लिए एक बफर के रूप में कार्य करता है जो इसे अक्सर स्थानीय नेटवर्क पर प्राप्त होता है (इस डेटा की अवधि 0.5s है, इसलिए काफी उच्च थ्रूपुट है)। प्राप्त किसी भी डेटा को वर्चुअल मशीन पर संग्रहीत किया जाता है और बार-बार यूडीपी पर एक बाहरी सर्वर को अग्रेषित किया जाता है। एक बार जब बाह्य सर्वर स्वीकार करता है (UDP से अधिक) कि उसे डेटा पैकेट प्राप्त हुआ है, तो मूल डेटा को वर्चुअल मशीन से हटा दिया जाता है और फिर से बाहरी सर्वर पर नहीं भेजा जाता है। वीएम और बाहरी सर्वर को जोड़ने वाला इंटरनेट कनेक्शन अविश्वसनीय है, जिसका अर्थ है कि यह एक समय में दिनों के लिए नीचे हो सकता है।

वीएम को होस्ट करने वाली भौतिक मशीन यादृच्छिक रूप से प्रति दिन कई बार बिजली काटती है। यह बताने का कोई तरीका नहीं है कि यह कब होने वाला है और यह यूपीएस, बैटरी, या सिस्टम के समान समाधान को जोड़ना संभव नहीं है।

मूल रूप से, डेटा वर्चुअल मशीन पर एक फ़ाइल-आधारित HSQLDB डेटाबेस पर संग्रहीत किया गया था। हालाँकि, लगातार बिजली कटौती अंततः डेटाबेस स्क्रिप्ट फ़ाइल को दूषित होने का कारण बनती है (फाइल सिस्टम स्तर पर नहीं, अर्थात यह पठनीय है, लेकिन HSQLDB इसका कोई मतलब नहीं निकाल सकता), जिससे मेरा प्रश्न बनता है:

डेटा को ऐसे वातावरण में कैसे संग्रहीत किया जाना चाहिए जहां बिजली कटौती हो सकती है और अक्सर होती है?

एक विकल्प जो मैं सोच सकता हूं, वह फ्लैट फाइल का उपयोग कर रहा है, फाइल सिस्टम पर एक फाइल के रूप में डेटा के प्रत्येक पैकेट को बचा रहा है। इस तरह से यदि कोई फ़ाइल शक्ति के नुकसान के कारण दूषित है, तो इसे अनदेखा किया जा सकता है और शेष डेटा बरकरार रहता है। हालाँकि, यह कुछ समस्याएँ हैं जो मुख्य रूप से वर्चुअल मशीन पर संग्रहीत डेटा की मात्रा से संबंधित है। प्रत्येक डेटा के बीच 0.5s पर, 10 दिनों में 1,728,000 फाइलें उत्पन्न होंगी। इस डेटा को संग्रहीत करने के लिए बढ़ी संख्या में इनोड्स के साथ फ़ाइल सिस्टम का उपयोग करने का कम से कम मतलब है (वर्तमान फ़ाइल सिस्टम सेटअप ~ 250,000 संदेशों और उपयोग किए गए 30% डिस्क स्थान पर इनोड से बाहर चला गया)। साथ ही, प्रबंधन करना कठिन (असंभव नहीं) है।

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

वर्चुअल मशीन पर चलने वाला सॉफ्टवेयर जावा 6 का उपयोग करके लिखा गया है, इसलिए उम्मीद है कि समाधान असंगत नहीं होगा।

Comments

"वीएम को होस्ट करने वाली भौतिक मशीन यादृच्छिक रूप से प्रति दिन कई बार बिजली कटौती करती है। यह बताने का कोई तरीका नहीं है कि यह कब होने वाला है और यूपीएस, बैटरी, या इसी तरह के समाधान को जोड़ना संभव नहीं है। सिस्टम। " मैं वास्तव में जानना चाहता हूं कि यह कैसे संभव है। क्या यह इंटरनेशनल स्पेस स्टेशन में है इसलिए यूपीएस या कुछ और भेजने के लिए 20 मिलियन डॉलर की आवश्यकता है?

— सिवायजोज़

क्या मशीन में बैटरी समर्थित कैश के साथ कम से कम एक RAID नियंत्रक है?

— Zoredache

हम इस समस्या के लिए बहुत ही रोचक, रचनात्मक और शायद सैद्धांतिक रूप से सही समाधान सुझा सकते हैं। हालाँकि , हम यह नहीं जानते कि मेजबान पर हाइपरवाइज़र और हार्डवेयर क्या चल रहा है, इसलिए इस बात की कोई गारंटी नहीं होगी कि डिस्क राइट्स वास्तव में लिखे गए हैं, या सही क्रम में लिखे गए हैं ...

— pino42

@ शेव्स लगता है कि यह आपकी कॉल नहीं है, लेकिन मैं सुझाव दूंगा कि यह इंगित करना उचित है कि 50 बुनियादी, सस्ते यूपीएस $ 2500 खर्च होंगे, और रखरखाव की आवश्यकता नहीं है (आप उन्हें दो साल के बाद प्रतिस्थापित करते हैं जब बैटरी शुरू होती हैं। )। सॉफ्टवेयर में इसे हल करने की कोशिश करने की लागत इससे कहीं अधिक होने वाली है, जब तक कि आप कोडर्स का एक गुच्छा नहीं जानते हैं जो मुफ्त में काम करते हैं। दर्जनों या सैकड़ों कुशल-घंटे @ 3-आंकड़े प्रति घंटे के बजाय $ 50 / यूनिट के लिए इसे हल करने के लिए प्रबंधन प्राप्त करने में मददगार हो सकता है।

— २३:१४

यह वास्तव में एक दुर्भावनापूर्ण कार्यक्रम की तरह लगता है। उपयोगकर्ता को पता नहीं है कि उनके कंप्यूटर पर "वीएम" चल रहा है। यह पूरे नेटवर्क से डेटा चुरा रहा है - फिर खुद को छिपाने के लिए इसे एक कनेक्शन के माध्यम से फ़नल कर रहा है। उपयोगकर्ता "कंप्यूटर को बंद कर देता है और" बेतरतीब ढंग से - तो आप बस एक यूपीएस जोड़ सकते हैं।

— लॉरेंस

Answer 1

ईमानदारी से यहां आपका सबसे अच्छा तरीका बिजली कटौती को ठीक करना है, या एक बेहतर स्थान पर एक अलग प्रणाली को तैनात करना है।

हाँ ऐसी प्रणालियाँ हैं जैसे कि रेडिस, जो रिप्ले के लिए एपेंड-ओनली-लॉग में डेटा स्टोर करेगी, लेकिन आप निचले स्तरों पर भ्रष्टाचार का जोखिम उठाते हैं - जैसे कि यदि आपका फाइल सिस्टम खंगाला जाता है, तो डिस्क पर डेटा संभावित रूप से जोखिम में है।

मैं सराहना करता हूं कि कोई भी सुधार आपके लिए उपयोगी होगा, लेकिन वास्तव में समस्या एक नहीं है जिसे आपके द्वारा उल्लिखित परिदृश्य को हल किया जा सकता है।

Comments

+1 सही उत्तर है "ऐसा मत करो"

— क्रिस एस

+1 अंततः यादृच्छिक बिजली कटौती आपके फाइल सिस्टम को दूषित कर देगी। इलेक्ट्रॉनिक्स अजीब अप्रत्याशित चीजें करते हैं क्योंकि उनकी शक्ति विफल हो जाती है।

— ग्रांट

-1 (आभासी -1)। मुझे लगता है कि इस तरह की प्रणाली का निर्माण इस धारणा पर किया जाना चाहिए कि बिजली कटौती समय-समय पर होती है। यह धारणा एक वास्तविक विश्व तथ्य है जिससे आपको निपटना होगा।

— इगेल सेर्बन

Answer 2

आपका दृष्टिकोण काम कर सकता है। मुझे इसे बढ़ाने के लिए कुछ सुझाव दें। फाइल करने के लिए परमाणु लेखन पर स्टैक अतिप्रवाह में एक सवाल था । अनिवार्य रूप से आप डेटा के प्रत्येक पैकेट को एक अस्थायी फ़ाइल में सहेजते हैं और फिर आप इसका नाम बदलकर इसे अंतिम नाम देते हैं। नाम बदलना एक परमाणु ऑपरेशन है जो बिजली की विफलता से सुरक्षित होगा। इस तरह से आपको गारंटी दी जाती है कि आपके अंतिम गंतव्य में आपकी सभी फाइलें बिना किसी भ्रष्टाचार के सही ढंग से बचाई गई हैं।

फिर लाखों फाइलें होने के मुद्दे से निपटने के लिए आप क्या कर सकते हैं। क्या क्रोन एक ऐसी नौकरी है जो शायद हर घंटे चलती है जो सभी फाइलों को एक घंटे बाद पुरानी कर देती है और उन्हें फिर से परमाणु फ़ाइल संचालन का उपयोग करके एक बड़ी फ़ाइल में जोड़ती है ताकि यह नौकरी एक शक्ति विफलता के दौरान भी सुरक्षित रूप से चलती है, और फिर पुरानी फ़ाइलों को हटा देती है। लॉग रोटेशन की तरह। एक घंटे की फाइलें लगभग 7,200 फाइलें होंगी। तो किसी भी समय आपके पास डिस्क पर 20,000 से अधिक फाइलें नहीं होनी चाहिए।

Comments

एक बुरा जवाब नहीं है, लेकिन इसके साथ समस्या यह मानकर है कि लेखन स्वयं एक परमाणु संचालन है, जो यह नहीं है। तो गलत समय पर बिजली की विफलता अभी भी डेटा या एफएस भ्रष्टाचार बना सकती है। संभवतः बिजली को ठीक करने के सबसे अच्छे विकल्प के बारे में, या किसी चीज़ को यूपीएस में प्लग करना, हालांकि, +1।

— HopelessN00b

@ होपलेस

— एनबीबी

हां, एक बार लिखी गई फ़ाइल का नाम बदलना एक परमाणु ऑपरेशन है। पहली जगह में फ़ाइल लिखना, नहीं है।

— होपलेस एनबीबी

@ HopelessN00b यह कोई फर्क नहीं पड़ता कि नई फ़ाइल आधी-लिखित या भ्रष्ट है। आपके पास पुरानी फ़ाइल है जो एक अच्छी स्थिति में है। जब आप सिस्टम को ठीक करते हैं तो आप आधी लिखी फाइल को नष्ट कर देते हैं।

— डीजेकेवर्थ 21

@ HopelessN00b बिल्कुल! एक अस्थायी निर्देशिका में केवल अस्थायी फाइलें कहती हैं कि कभी भी आधा लिखा जा सकता है। आपके अंतिम गंतव्य निर्देशिका की सभी फाइलें डिस्क पर हमेशा गैर-भ्रष्ट और सुरक्षित

— रहेंगी

Answer 3

आप सिस्टम में बैटरी-समर्थित राइट कैश के साथ एक UPS या RAID कार्ड स्थापित करते हैं, और $ 49.95 के रूप में बहुत कम के लिए , आप केवल सॉफ्टवेयर में पूरा करना असंभव है।

आपका दावा है कि किसी तरह इस सर्वर को यूपीएस या बैटरी तक हुक करना संभव नहीं है ... बस विश्वास करने योग्य नहीं है।

Comments

नौकरशाही की मूर्खता हमेशा विश्वसनीय होती है।

— दान 21

@ डैनीली My PHB won't let me hook this up to a UPS/batteryबहुत अलग चीज है it is not possible to add a UPS, a battery, or a similar solution to the system. न कि बहुत ज्यादा पांडित्य से, लेकिन यह एक महत्वपूर्ण अंतर है क्योंकि यह उपलब्ध दृष्टिकोण और समाधान को बदल देता है।

— HopelessN00b

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

— 15

@WernerCD मैं चाहूंगा कि आप हमारे CIO से मिलें। जबकि मैं मानता हूं कि किसी के कंप्यूटर को अपहरण करना इसके लिए संभव उपयोग का मामला है, मैं वैध लोगों के बारे में भी सोच सकता हूं, इसलिए मैं उस व्यक्ति को संदेह का लाभ दूंगा। एम्बेडेड सिस्टम और नियंत्रकों के बारे में सोचें, या रास्पबेरी पाई की तरह - यह निश्चित रूप से ऐसा हो सकता है कि आप जिस "कंप्यूटर" का उपयोग कर रहे हैं वह $ 50 से कम मूल्य का है जो इसे यूपीएस में संलग्न करने के लिए ले जाएगा।

— होपलेस एनबीबी

भले ही कंप्यूटर $ 50 यूपीएस से कम मूल्य का है - यह कंप्यूटर पर डेटा है जो वास्तव में कुछ के लायक है। Google "बेकार" कंप्यूटरों पर बनाया गया था। सीपीयू की लागत से अधिक महत्वपूर्ण है खोए हुए डेटा की लागत, खोया हुआ मैन-पॉवर (यह प्रोग्रामिंग साहसिक, डेटा भ्रष्टाचार का पीछा करना, पुरानी प्रणाली में बग ट्रैकिंग और साथ ही इस नए हिस्से में), खोए हुए ग्राहक मूल्य (मेरा डेटा खो दिया है? अगली कंपनी कृपया।), आदि

— WernerCD

Answer 4

एक ब्लॉक डिवाइस को छोड़कर पूरे सिस्टम को केवल पढ़ने के लिए माउंट करें, जो आपके सभी डेटा को स्टोर करता है। सीधे उस ब्लॉक डिवाइस का उपयोग करें और उस कच्चे ब्लॉक डिवाइस का उपयोग करके अपने स्वयं के डेटा भंडारण तंत्र को लागू करें।

Comments

... और बैटरी-समर्थित डिस्क नियंत्रक कार्ड में निवेश करें, और सुनिश्चित करें कि डिस्क पर कोई लेखन-कैश नहीं है, या आप अभी भी खराब हैं।

— voretaq7

कहने का मतलब यह है कि उन्हें लाइव-सीडी या समतुल्य रॉम प्रणाली से बूट होना चाहिए, जिसमें कुछ ठोस अवस्था में समतल फ़ाइल समाधान के साथ उपयोग किया जाता है।

— मार्क एलन

राइट कैश को अक्षम किया जा सकता है। यह दृष्टिकोण व्यवहार्य है। केवल संग्रहण तंत्र की सलाह दें। ब्लॉक एटोमिक रूप से लिखे गए हैं (मुझे लगता है) इसलिए आपके पास दो "पॉइंटर" ब्लॉक हो सकते हैं जो नए / टूडू डेटा के साथ अनुभाग के शुरू और अंत की ओर इशारा करते हैं। डेटा लिखने / खत्म करने के बाद संकेत अपडेट किए जाते हैं। NCQ को भी अक्षम किया जाना चाहिए।

— आस्तीनदार