Oracle RAC र AccelStor Shared-Nothing आर्किटेक्चरमा आधारित त्रुटि-सहिष्णु समाधान निर्माण गर्दै

इन्टरप्राइज अनुप्रयोगहरू र भर्चुअलाइजेशन प्रणालीहरूको पर्याप्त संख्यामा दोष-सहिष्णु समाधानहरू निर्माण गर्नका लागि आफ्नै संयन्त्रहरू छन्। विशेष रूपमा, Oracle RAC (Oracle Real Application Cluster) दुई वा बढी Oracle डाटाबेस सर्भरहरूको क्लस्टर हो जसले लोडलाई सन्तुलनमा राख्न र सर्भर/एप्लिकेशन स्तरमा त्रुटि सहिष्णुता प्रदान गर्दछ। यस मोडमा काम गर्न, तपाईंलाई साझा भण्डारण चाहिन्छ, जुन सामान्यतया भण्डारण प्रणाली हो।

जसरी हामीले पहिले नै हाम्रो एउटामा छलफल गरिसकेका छौं लेखहरू, भण्डारण प्रणाली आफैं, डुप्लिकेट कम्पोनेन्टहरू (नियन्त्रकहरू सहित) को उपस्थितिको बावजुद, अझै पनि विफलताको बिन्दुहरू छन् - मुख्य रूपमा डेटाको एकल सेटको रूपमा। त्यसकारण, बढ्दो विश्वसनीयता आवश्यकताहरूको साथ ओरेकल समाधान निर्माण गर्न, "N सर्भर - एक भण्डारण प्रणाली" योजना जटिल हुनु आवश्यक छ।

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

यी क्याबिनेटहरूमा उपकरण र सफ्टवेयरको सम्पूर्ण आवश्यक सेट हुनुपर्दछ जसले "छिमेकी" को अवस्थालाई ध्यान नदिई ओरेकल डाटाबेसहरूको सञ्चालनलाई अनुमति दिनेछ। अन्य शब्दहरूमा, क्रस-र्याक आपदा रिकभरी समाधान प्रयोग गरेर, हामी असफलताको जोखिमहरू हटाउँछौं:

• ओरेकल अनुप्रयोग सर्भर
• भण्डारण प्रणालीहरू
• स्विचिङ प्रणालीहरू
• क्याबिनेटमा सबै उपकरणहरूको पूर्ण विफलता:
  • शक्ति अस्वीकार
  • शीतलन प्रणाली विफलता
  • बाह्य कारकहरू (मानव, प्रकृति, आदि)

Oracle सर्भरहरूको नक्कलले Oracle RAC को धेरै सञ्चालन सिद्धान्तलाई बुझाउँछ र एउटा अनुप्रयोग मार्फत लागू गरिन्छ। स्विचिंग सुविधाहरूको नक्कल पनि समस्या होइन। तर भण्डारण प्रणाली को नक्कल संग, सबै कुरा यति सरल छैन।

सबैभन्दा सरल विकल्प मुख्य भण्डारण प्रणालीबाट ब्याकअप एकमा डाटा प्रतिकृति हो। सिंक्रोनस वा एसिन्क्रोनस, भण्डारण प्रणालीको क्षमताहरूमा निर्भर गर्दछ। एसिन्क्रोनस प्रतिकृतिको साथ, Oracle को सम्बन्धमा डाटा स्थिरता सुनिश्चित गर्ने प्रश्न तुरुन्तै उठ्छ। तर यदि त्यहाँ अनुप्रयोगसँग सफ्टवेयर एकीकरण छ भने, कुनै पनि अवस्थामा, मुख्य भण्डारण प्रणालीमा विफलताको घटनामा, क्लस्टरलाई ब्याकअप भण्डारणमा स्विच गर्न प्रशासकहरूद्वारा म्यानुअल हस्तक्षेप आवश्यक हुनेछ।

थप जटिल विकल्प सफ्टवेयर र/वा हार्डवेयर भण्डारण "भर्चुअलाइजरहरू" हो जसले स्थिरता समस्याहरू र म्यानुअल हस्तक्षेपहरू हटाउनेछ। तर तैनाती र त्यसपछिको प्रशासनको जटिलता, साथै त्यस्ता समाधानहरूको अत्यन्तै अशोभनीय लागतले धेरैलाई डराउँछ।

AccelStor NeoSapphire™ सबै फ्ल्यास एरे समाधान क्रस-र्याक आपदा रिकभरी जस्ता परिदृश्यहरूको लागि उपयुक्त छ। H710 साझा-कुनै पनि वास्तुकला प्रयोग गर्दै। यो मोडेल दुई-नोड भण्डारण प्रणाली हो जसले फ्ल्याश ड्राइभहरूसँग काम गर्न स्वामित्वको FlexiRemap® प्रविधि प्रयोग गर्दछ। लाई धन्यवाद FlexiRemap® NeoSapphire™ H710 ले 600K IOPS@4K यादृच्छिक लेखन र 1M+ IOPS@4K यादृच्छिक पढाइसम्म प्रदर्शन प्रदान गर्न सक्षम छ, जुन क्लासिक RAID-आधारित भण्डारण प्रणालीहरू प्रयोग गर्दा अप्राप्य हुन्छ।

तर NeoSapphire™ H710 को मुख्य विशेषता भनेको दुईवटा नोडहरू अलग-अलग केसहरूको रूपमा कार्यान्वयन गर्नु हो, जसमध्ये प्रत्येकको डेटाको आफ्नै प्रतिलिपि छ। नोडहरूको सिंक्रोनाइजेसन बाह्य InfiniBand इन्टरफेस मार्फत गरिन्छ। यस वास्तुकलाको लागि धन्यवाद, 100m सम्मको दूरीमा विभिन्न स्थानहरूमा नोडहरू वितरण गर्न सम्भव छ, जसले गर्दा क्रस-र्याक आपदा रिकभरी समाधान प्रदान गर्दछ। दुबै नोडहरू पूर्ण रूपमा सिंक्रोनस रूपमा काम गर्छन्। होस्ट पक्षबाट, H710 एक साधारण दोहोरो-नियन्त्रक भण्डारण प्रणाली जस्तो देखिन्छ। त्यसकारण, त्यहाँ कुनै अतिरिक्त सफ्टवेयर वा हार्डवेयर विकल्पहरू वा विशेष गरी जटिल सेटिङहरू प्रदर्शन गर्न आवश्यक छैन।

यदि हामीले माथि वर्णन गरिएका सबै क्रस-र्याक आपदा रिकभरी समाधानहरू तुलना गर्छौं भने, AccelStor को विकल्प बाँकीबाट उल्लेखनीय रूपमा खडा हुन्छ:

AccelStor NeoSapphire™ साझा गरिएको छैन वास्तुकला
सफ्टवेयर वा हार्डवेयर "भर्चुअलाइजर" भण्डारण प्रणाली
प्रतिकृति आधारित समाधान

उपलब्धता

सर्भर विफलता
कुनै डाउनटाइम छैन
कुनै डाउनटाइम छैन
कुनै डाउनटाइम छैन

स्विच विफलता
कुनै डाउनटाइम छैन
कुनै डाउनटाइम छैन
कुनै डाउनटाइम छैन

भण्डारण प्रणाली विफलता
कुनै डाउनटाइम छैन
कुनै डाउनटाइम छैन
डाउनटाइम

मन्त्रिपरिषद्को पूर्ण असफलता
कुनै डाउनटाइम छैन
कुनै डाउनटाइम छैन
डाउनटाइम

लागत र जटिलता

समाधान लागत
कम*
Высокая
Высокая

परिनियोजन जटिलता
कम
Высокая
Высокая

*AccelStor NeoSapphire™ अझै पनि एक All Flash array हो, जसको परिभाषा अनुसार "3 kopecks" खर्च गर्दैन, विशेष गरी योसँग डबल क्षमता रिजर्भ भएकोले। यद्यपि, अन्य विक्रेताहरूबाट मिल्दोजुल्दो समाधानमा आधारित समाधानको अन्तिम लागत तुलना गर्दा, लागत कम मान्न सकिन्छ।

एप्लिकेसन सर्भरहरू र सबै फ्ल्यास एरे नोडहरू जडान गर्नको लागि टोपोलोजी यस्तो देखिनेछ:

टोपोलोजी योजना बनाउँदा, व्यवस्थापन स्विचहरू र इन्टरकनेक्ट सर्भरहरू डुप्लिकेट गर्न पनि अत्यधिक सिफारिस गरिन्छ।

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

एरे मा तयारी कार्य

उपकरण र सफ्टवेयर प्रयोग

सर्भर र स्विच निर्दिष्टीकरण

अवयव
विवरण

ओरेकल डाटाबेस 11g सर्भरहरू
दुई

सर्भर अपरेटिङ सिस्टम
ओरेकल लिनक्स

ओरेकल डाटाबेस संस्करण
11g (RAC)

प्रति सर्भर प्रोसेसर
दुई 16 कोर Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz

प्रति सर्भर भौतिक मेमोरी
128GB

एफसी नेटवर्क
मल्टिपाथिङको साथ 16Gb/s FC

एफसी एचबीए
Emulex Lpe-16002B

क्लस्टर व्यवस्थापनको लागि समर्पित सार्वजनिक 1GbE पोर्टहरू
इंटेल इथरनेट एडाप्टर RJ45

16Gb/s FC स्विच
ब्रोकेड 6505 १।

डाटा सिङ्कनाइजेसनको लागि समर्पित निजी 10GbE पोर्टहरू
इंटेल X520

AccelStor NeoSapphire™ सबै फ्ल्यास एरे विशिष्टता

अवयव
विवरण

भण्डारण प्रणाली
NeoSapphire™ उच्च उपलब्धता मोडेल: H710

छवि संस्करण
4.0.1

ड्राइभहरूको कुल संख्या
48

ड्राइभ आकार
1.92TB

ड्राइभ प्रकार
SSD

एफसी लक्ष्य पोर्टहरू
16x 16Gb पोर्टहरू (8 प्रति नोड)

व्यवस्थापन पोर्टहरू
1GbE इथरनेट केबल एक इथरनेट स्विच मार्फत होस्टहरूमा जडान हुन्छ

मुटुको धड्कन पोर्ट
दुई भण्डारण नोडहरू बीच जडान गर्ने 1GbE इथरनेट केबल

डाटा सिंक्रोनाइजेसन पोर्ट
56Gb/s InfiniBand केबल

तपाईंले एरे प्रयोग गर्न सक्नु अघि, तपाईंले यसलाई प्रारम्भ गर्नुपर्छ। पूर्वनिर्धारित रूपमा, दुबै नोडहरूको नियन्त्रण ठेगाना समान छ (192.168.1.1)। तपाईंले तिनीहरूलाई एक एक गरेर जडान गर्न र नयाँ (पहिले नै फरक) व्यवस्थापन ठेगानाहरू सेट गर्न र समय सिङ्क्रोनाइजेसन सेट अप गर्न आवश्यक छ, जस पछि व्यवस्थापन पोर्टहरू एकल नेटवर्कमा जडान गर्न सकिन्छ। पछि, नोडहरू इन्टरलिङ्क जडानहरूको लागि सबनेटहरू असाइन गरेर HA जोडीमा जोडिन्छन्।

प्रारम्भ पूरा भएपछि, तपाइँ कुनै पनि नोडबाट एरे व्यवस्थापन गर्न सक्नुहुन्छ।

अर्को, हामी आवश्यक भोल्युमहरू सिर्जना गर्छौं र तिनीहरूलाई अनुप्रयोग सर्भरहरूमा प्रकाशित गर्छौं।

Oracle ASM का लागि धेरै भोल्युमहरू सिर्जना गर्न यो अत्यधिक सिफारिस गरिएको छ किनकि यसले सर्भरहरूको लागि लक्ष्यहरूको संख्या बढाउनेछ, जसले अन्ततः समग्र प्रदर्शनमा सुधार गर्नेछ (अर्कोमा लामहरूमा थप। लेख).

परीक्षण कन्फिगरेसन

भण्डारण मात्रा नाम
भोल्यूम आकार

डाटा 01
200GB

डाटा 02
200GB

डाटा 03
200GB

डाटा 04
200GB

डाटा 05
200GB

डाटा 06
200GB

डाटा 07
200GB

डाटा 08
200GB

डाटा 09
200GB

डाटा 10
200GB

Grid01
1GB

Grid02
1GB

Grid03
1GB

Grid04
1GB

Grid05
1GB

Grid06
1GB

Redo01
100GB

Redo02
100GB

Redo03
100GB

Redo04
100GB

Redo05
100GB

Redo06
100GB

Redo07
100GB

Redo08
100GB

Redo09
100GB

Redo10
100GB

एरेको अपरेटिङ मोडहरू र आपतकालीन अवस्थाहरूमा हुने प्रक्रियाहरू बारे केही स्पष्टीकरणहरू

प्रत्येक नोडको डेटा सेटमा "संस्करण नम्बर" प्यारामिटर हुन्छ। प्रारम्भिक प्रारम्भिकरण पछि, यो समान र 1 को बराबर छ। यदि कुनै कारणले संस्करण नम्बर फरक छ भने, डेटा सधैं पुरानो संस्करणबाट सानो संस्करणमा सिंक्रोनाइज गरिन्छ, जस पछि सानो संस्करणको संख्या पङ्क्तिबद्ध हुन्छ, अर्थात्। यसको मतलब प्रतिलिपिहरू समान छन्। संस्करणहरू फरक हुन सक्ने कारणहरू:

• नोडहरू मध्ये एकको अनुसूचित रिबुट
• अचानक बन्द (बिजुली आपूर्ति, ओभरहेटिंग, आदि) को कारण नोड्स मध्ये एक मा दुर्घटना।
• सिङ्क्रोनाइज गर्न असक्षमता संग InfiniBand जडान हराएको छ
• डाटा भ्रष्टाचारको कारण नोडहरू मध्ये एउटामा क्र्यास। यहाँ तपाईंले नयाँ HA समूह र डेटा सेटको पूर्ण सिंक्रोनाइजेसन सिर्जना गर्न आवश्यक छ।

कुनै पनि अवस्थामा, जोडासँग जडान पुनर्स्थापित भएपछि यसको डेटा सेट सिङ्क्रोनाइज गर्नको लागि अनलाइन रहने नोडले यसको संस्करण नम्बर एकले बढाउँछ।

यदि इथरनेट लिङ्कमा जडान हराएको छ भने, हार्टबिट अस्थायी रूपमा InfiniBand मा स्विच हुन्छ र 10 सेकेन्ड भित्र फिर्ता हुन्छ जब यो पुनर्स्थापित हुन्छ।

होस्टहरू सेट अप गर्दै

त्रुटि सहिष्णुता सुनिश्चित गर्न र कार्यसम्पादन सुधार गर्न, तपाईंले एरेको लागि MPIO समर्थन सक्षम गर्नुपर्छ। यो गर्नको लागि, तपाईंले /etc/multipath.conf फाइलमा लाइनहरू थप्नु पर्छ, र त्यसपछि मल्टिपाथ सेवा पुन: सुरु गर्नुहोस्।

लुकेको पाठउपकरणहरू {
उपकरण {
विक्रेता "AStor"
path_grouping_policy "group_by_prio"
पथ_चयनकर्ता "लाम-लम्बाइ ०"
path_checker "tur"
सुविधाहरू "०"
हार्डवेयर_ह्यान्डलर "०"
prio "const"
तत्काल असफल
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names हो
detect_prio हो
rr_min_io_rq १
no_path_retry ०
}
}

अर्को, ASM लाई ASMLib मार्फत MPIO सँग काम गर्नको लागि, तपाईंले /etc/sysconfig/oracleasm फाइल परिवर्तन गर्नुपर्नेछ र त्यसपछि /etc/init.d/oracleasm scandisks चलाउनुहोस्।

लुकेको पाठ

# ORACLEASM_SCANORDER: डिस्क स्क्यानिङ अर्डर गर्न मिल्दो ढाँचाहरू
ORACLEASM_SCANORDER="dm"

# ORACLEASM_SCANEXCLUDE: स्क्यानबाट डिस्कहरू बहिष्कार गर्न मिल्दो ढाँचाहरू
ORACLEASM_SCANEXCLUDE="sd"

भन्नु

यदि तपाइँ ASMLib प्रयोग गर्न चाहनुहुन्न भने, तपाइँ UDEV नियमहरू प्रयोग गर्न सक्नुहुन्छ, जुन ASMLib को आधार हो।

Oracle डाटाबेसको संस्करण 12.1.0.2 बाट सुरु गर्दै, विकल्प ASMFD सफ्टवेयरको भागको रूपमा स्थापनाको लागि उपलब्ध छ।

यो सुनिश्चित गर्न अनिवार्य छ कि Oracle ASM का लागि सिर्जना गरिएका डिस्कहरू ब्लक साइजसँग पङ्क्तिबद्ध छन् जुन array शारीरिक रूपमा (4K) सँग सञ्चालन हुन्छ। अन्यथा, प्रदर्शन समस्या हुन सक्छ। त्यसकारण, उपयुक्त प्यारामिटरहरूसँग भोल्युमहरू सिर्जना गर्न आवश्यक छ:

parted /dev/mapper/device-name mklabel gpt mkpart प्राथमिक 2048s 100% align-check इष्टतम 1

हाम्रो परीक्षण कन्फिगरेसनको लागि सिर्जना गरिएको भोल्युमहरूमा डाटाबेसहरूको वितरण

भण्डारण मात्रा नाम
भोल्यूम आकार
भोल्युम LUNs म्यापिङ
ASM भोल्युम यन्त्र विवरण
आवंटन एकाइ आकार

डाटा 01
200GB
भण्डारण प्रणालीमा सबै डाटा पोर्टहरूमा सबै भण्डारण मात्राहरू नक्सा गर्नुहोस्
रिडन्डन्सी: सामान्य
नाम: DGDATA
उद्देश्य: डाटा फाइलहरू

4MB

डाटा 02
200GB

डाटा 03
200GB

डाटा 04
200GB

डाटा 05
200GB

डाटा 06
200GB

डाटा 07
200GB

डाटा 08
200GB

डाटा 09
200GB

डाटा 10
200GB

Grid01
1GB
रिडन्डन्सी: सामान्य
नाम: DGGRID1
उद्देश्य: ग्रिड: CRS र मतदान

4MB

Grid02
1GB

Grid03
1GB

Grid04
1GB
रिडन्डन्सी: सामान्य
नाम: DGGRID2
उद्देश्य: ग्रिड: CRS र मतदान

4MB

Grid05
1GB

Grid06
1GB

Redo01
100GB
रिडन्डन्सी: सामान्य
नाम: DGREDO1
उद्देश्य: थ्रेड 1 को लग पुन: गर्नुहोस्

4MB

Redo02
100GB

Redo03
100GB

Redo04
100GB

Redo05
100GB

Redo06
100GB
रिडन्डन्सी: सामान्य
नाम: DGREDO2
उद्देश्य: थ्रेड 2 को लग पुन: गर्नुहोस्

4MB

Redo07
100GB

Redo08
100GB

Redo09
100GB

Redo10
100GB

डाटाबेस सेटिङहरू

• ब्लक साइज = 8K
• स्वैप स्पेस = 16GB
• AMM (स्वचालित मेमोरी व्यवस्थापन) असक्षम गर्नुहोस्
• पारदर्शी विशाल पृष्ठहरू असक्षम गर्नुहोस्

अन्य सेटिङहरू

# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-max = 6815744
✓ kernel.shmmax 103079215104
✓ kernel.shmall 31457280
✓ kernel.shmmn 4096
✓ kernel.sem = 250 32000 100 128
✓ net.ipv4.ip_local_port_range = 9000 65500
✓ net.core.rmem_default = 262144
✓ net.core.rmem_max = 4194304
✓ net.core.wmem_default = 262144
✓ net.core.wmem_max = 1048586
✓vm.swappiness=10
✓ vm.min_free_kbytes=524288 # यदि तपाइँ लिनक्स x86 प्रयोग गर्दै हुनुहुन्छ भने यसलाई सेट नगर्नुहोस्
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000

# vi /etc/security/limits.conf
✓ ग्रिड सफ्ट nproc 2047
✓ ग्रिड हार्ड nproc 16384
✓ ग्रिड सफ्ट नोफाइल 1024
✓ ग्रिड हार्ड नोफाइल 65536
✓ ग्रिड सफ्ट स्ट्याक 10240
✓ ग्रिड हार्ड स्ट्याक 32768
✓ ओरेकल सफ्ट एनप्रोक 2047
✓ ओरेकल हार्ड एनप्रोक 16384
✓ ओरेकल सफ्ट नोफाइल 1024
✓ ओरेकल हार्ड नोफाइल 65536
✓ ओरेकल सफ्ट स्ट्याक 10240
✓ ओरेकल हार्ड स्ट्याक 32768
✓ सफ्ट मेमलक 120795954
✓ हार्ड मेमलक 120795954

sqlplus "/ as sysdba"
प्रणाली सेट प्रक्रियाहरू परिवर्तन गर्नुहोस् = 2000 स्कोप = spfile;
परिवर्तन प्रणाली सेट open_cursors=2000 scope=spfile;
परिवर्तन प्रणाली सेट session_cached_cursors=300 scope=spfile;
परिवर्तन प्रणाली सेट db_files=8192 scope=spfile;

असफलता परीक्षण

प्रदर्शन उद्देश्यका लागि, HammerDB लाई OLTP लोड अनुकरण गर्न प्रयोग गरिएको थियो। HammerDB कन्फिगरेसन:

गोदामहरूको संख्या
256

प्रति प्रयोगकर्ता कुल लेनदेन
1000000000000

भर्चुअल प्रयोगकर्ताहरू
256

नतिजा 2.1M TPM थियो, जुन array को प्रदर्शन सीमा भन्दा टाढा छ H710, तर सर्भरहरूको हालको हार्डवेयर कन्फिगरेसन (मुख्य रूपमा प्रोसेसरहरूको कारणले) र तिनीहरूको संख्याको लागि "छत" हो। यस परीक्षणको उद्देश्य अझै पनि समग्र रूपमा समाधानको गल्ती सहिष्णुता प्रदर्शन गर्नु हो, र अधिकतम प्रदर्शन प्राप्त गर्न होइन। त्यसकारण, हामी केवल यो आंकडामा निर्माण गर्नेछौं।

नोड मध्ये एक को विफलता को लागी परीक्षण

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

सबै उपकरणको साथ क्याबिनेट असफलता परीक्षण

यस अवस्थामा, मार्गहरूको पुनर्संरचनाको कारण प्रदर्शन पनि केही सेकेन्डको लागि घट्यो, र त्यसपछि मूल मानको आधामा फर्कियो। एउटा एप्लिकेसन सर्भर सञ्चालनमा नआएपछि नतिजा प्रारम्भिकबाट आधा घटेको थियो। सेवा प्रवाहमा पनि कुनै अवरोध आएको छैन ।

Oracle को लागि उचित लागतमा र थोरै परिनियोजन/प्रशासन प्रयासको साथ दोष-सहिष्णु क्रस-र्याक आपदा रिकभरी समाधान लागू गर्न आवश्यक छ भने, Oracle RAC र वास्तुकला सँगै काम गर्दछ। AccelStor साझा - केहि छैन सबै भन्दा राम्रो विकल्प मध्ये एक हुनेछ। Oracle RAC को सट्टा, त्यहाँ कुनै अन्य सफ्टवेयर हुन सक्छ जसले क्लस्टरिङ प्रदान गर्दछ, उही DBMS वा भर्चुअलाइजेशन प्रणालीहरू, उदाहरणका लागि। समाधान निर्माणको सिद्धान्त उस्तै रहनेछ। र RTO र RPO को लागि तल्लो रेखा शून्य छ।

स्रोत: www.habr.com