Oracle RAC እና AcelStor Shared-Nothing architecture ላይ የተመሰረተ ስህተትን የሚቋቋም መፍትሄ መገንባት

በርካታ ቁጥር ያላቸው የኢንተርፕራይዝ አፕሊኬሽኖች እና የቨርቹዋል አሰራር ስርዓቶች ስህተትን የሚቋቋሙ መፍትሄዎችን ለመገንባት የራሳቸው ዘዴዎች አሏቸው። በተለይም Oracle RAC (Oracle Real Application Cluster) ሸክምን ለማመጣጠን እና በአገልጋይ/በመተግበሪያ ደረጃ ስህተት መቻቻልን ለመስጠት አብረው የሚሰሩ የሁለት ወይም ከዚያ በላይ የOracle የውሂብ ጎታ አገልጋዮች ስብስብ ነው። በዚህ ሁነታ ለመስራት, የጋራ ማከማቻ ያስፈልግዎታል, ይህም ብዙውን ጊዜ የማከማቻ ስርዓት ነው.

በአንደኛው ውስጥ አስቀድመን እንደተነጋገርነው ጽሑፎች, የማከማቻ ስርዓቱ ራሱ, የተባዙ አካላት (ተቆጣጣሪዎችን ጨምሮ) ቢኖሩም, አሁንም ውድቀቶች አሉት - በዋናነት በአንድ የውሂብ ስብስብ መልክ. ስለዚህ የOracle መፍትሄን ከተጨማሪ አስተማማኝነት መስፈርቶች ጋር ለመገንባት “N አገልጋዮች - አንድ የማከማቻ ስርዓት” እቅድ ውስብስብ መሆን አለበት።

Oracle RAC እና AcelStor Shared-Nothing architecture ላይ የተመሰረተ ስህተትን የሚቋቋም መፍትሄ መገንባት

በመጀመሪያ፣ በእርግጥ፣ ምን ዓይነት አደጋዎችን ለመድን እየሞከርን እንዳለን መወሰን አለብን። በዚህ ጽሑፍ ውስጥ እንደ “ሜትሮይት መጥቷል” ካሉ አደጋዎች ጥበቃን አናስብም። ስለዚህ በጂኦግራፊያዊ የተበታተነ የአደጋ ማገገሚያ መፍትሄ መገንባት ከሚከተሉት መጣጥፎች ውስጥ የአንዱ ርዕስ ሆኖ ይቆያል። እዚህ በአገልጋይ ካቢኔዎች ደረጃ ጥበቃ ሲገነባ የ Cross-Rack አደጋ መልሶ ማግኛ መፍትሄ ተብሎ የሚጠራውን እንመለከታለን. ካቢኔዎች እራሳቸው በአንድ ክፍል ውስጥ ወይም በተለያየ ክፍል ውስጥ ሊቀመጡ ይችላሉ, ግን አብዛኛውን ጊዜ በአንድ ሕንፃ ውስጥ.

እነዚህ ካቢኔቶች የ "ጎረቤት" ሁኔታ ምንም ይሁን ምን የ Oracle የውሂብ ጎታዎችን አሠራር የሚያረጋግጥ ሙሉውን አስፈላጊ የመሳሪያ እና የሶፍትዌር ስብስብ መያዝ አለባቸው. በሌላ አገላለጽ የመስቀል-ራክ አደጋ መልሶ ማግኛ መፍትሄን በመጠቀም የውድቀት አደጋዎችን እናስወግዳለን፡-

  • Oracle መተግበሪያ አገልጋዮች
  • የማከማቻ ስርዓቶች
  • የመቀየሪያ ስርዓቶች
  • በካቢኔ ውስጥ ያሉት ሁሉም መሳሪያዎች ሙሉ በሙሉ አለመሳካት;
    • የኃይል እምቢታ
    • የማቀዝቀዣ ሥርዓት አለመሳካት
    • ውጫዊ ሁኔታዎች (ሰው, ተፈጥሮ, ወዘተ.)

የOracle አገልጋዮችን ማባዛት የOracle RACን ኦፕሬቲንግ መርሆ የሚያመለክተው እና በመተግበሪያ በኩል ነው። የመቀያየር መገልገያዎችን ማባዛትም ችግር አይደለም. ነገር ግን የማከማቻ ስርዓቱን በማባዛት ሁሉም ነገር በጣም ቀላል አይደለም.

በጣም ቀላሉ አማራጭ ከዋናው የማከማቻ ስርዓት ወደ መጠባበቂያው የውሂብ ማባዛት ነው. የተመሳሰለ ወይም ያልተመሳሰለ፣ በማከማቻ ስርዓቱ አቅም ላይ በመመስረት። ባልተመሳሰል ማባዛት፣ ከኦራክል ጋር በተገናኘ የውሂብን ወጥነት የማረጋገጥ ጥያቄ ወዲያውኑ ይነሳል። ነገር ግን ከመተግበሪያው ጋር የሶፍትዌር ውህደት ቢኖርም, በማንኛውም ሁኔታ, በዋናው የማከማቻ ስርዓት ላይ ውድቀት ካለ, ክላስተር ወደ ምትኬ ማከማቻ ለመቀየር በአስተዳዳሪዎች በእጅ ጣልቃ መግባት ያስፈልጋል.

በጣም የተወሳሰበ አማራጭ የሶፍትዌር እና/ወይም የሃርድዌር ማከማቻ “virtualizers” ሲሆን ይህም ወጥነት ያላቸውን ችግሮች እና በእጅ ጣልቃገብነት ያስወግዳል። ነገር ግን የማሰማራቱ ውስብስብነት እና ተከታይ አስተዳደር፣እንዲሁም የእንደዚህ አይነት መፍትሄዎች ጨዋነት የጎደለው ወጪ ብዙዎችን ያስፈራቸዋል።

የAcelStor NeoSapphire™ ሁሉም የፍላሽ ድርድር መፍትሄ እንደ ክሮስ-ራክ አደጋ መልሶ ማግኛ ላሉ ሁኔታዎች ፍጹም ነው። H710 የተጋራ-ምንም አርክቴክቸር በመጠቀም። ይህ ሞዴል ከፍላሽ አንፃፊዎች ጋር ለመስራት የባለቤትነት FlexiRemap® ቴክኖሎጂን የሚጠቀም ባለ ሁለት-ኖድ ማከማቻ ስርዓት ነው። ይመስገን FlexiRemap® NeoSapphire™ H710 እስከ 600K IOPS@4K የዘፈቀደ ፅሁፍ እና 1M+ IOPS@4K የዘፈቀደ ንባብ አፈጻጸምን ለማቅረብ የሚችል ነው፣ይህም ክላሲክ RAID ላይ የተመሰረቱ የማከማቻ ስርዓቶችን ሲጠቀም ሊደረስበት የማይችል ነው።

ነገር ግን የNeoSapphire ™ H710 ዋና ገፅታ የሁለት አንጓዎች አፈፃፀም በተለየ ጉዳዮች መልክ ነው ፣ እያንዳንዱም የራሱ የሆነ የመረጃ ቅጂ አለው። የአንጓዎች ማመሳሰል የሚከናወነው በውጫዊው InfiniBand በይነገጽ በኩል ነው። ለዚህ አርክቴክቸር ምስጋና ይግባውና እስከ 100 ሜትር ርቀት ላይ በተለያዩ ቦታዎች ላይ ኖዶችን ማሰራጨት ይቻላል, በዚህም የ Cross-Rack አደጋ መልሶ ማግኛ መፍትሄ ይሰጣል. ሁለቱም አንጓዎች ሙሉ በሙሉ በተመሳሳይ መልኩ ይሰራሉ። ከአስተናጋጁ ጎን, H710 እንደ ተራ ባለ ሁለት መቆጣጠሪያ ማከማቻ ስርዓት ይመስላል. ስለዚህ, ምንም ተጨማሪ የሶፍትዌር ወይም የሃርድዌር አማራጮችን ወይም በተለይ ውስብስብ ቅንብሮችን ማከናወን አያስፈልግም.

ከላይ የተገለጹትን ሁሉንም የ Cross-Rack አደጋ መልሶ ማግኛ መፍትሄዎችን ካነፃፅር፣ ከ AcelStor ያለው አማራጭ ከሌሎች በተለየ ሁኔታ ጎልቶ ይታያል።

AcelStor NeoSapphire™ ምንም ነገር አልተጋራም አርክቴክቸር
ሶፍትዌር ወይም ሃርድዌር "virtualizer" ማከማቻ ስርዓት
በማባዛት ላይ የተመሰረተ መፍትሄ

መገኘት

የአገልጋይ አለመሳካት።
ሰዓት አላፊ ሰዓት የለም
ሰዓት አላፊ ሰዓት የለም
ሰዓት አላፊ ሰዓት የለም

የመቀየሪያ አለመሳካት።
ሰዓት አላፊ ሰዓት የለም
ሰዓት አላፊ ሰዓት የለም
ሰዓት አላፊ ሰዓት የለም

የማከማቻ ስርዓት አለመሳካት
ሰዓት አላፊ ሰዓት የለም
ሰዓት አላፊ ሰዓት የለም
ታግዷል

አጠቃላይ የካቢኔ ውድቀት
ሰዓት አላፊ ሰዓት የለም
ሰዓት አላፊ ሰዓት የለም
ታግዷል

ወጪ እና ውስብስብነት

የመፍትሄው ዋጋ
ዝቅተኛ*
Высокая
Высокая

የመዘርጋት ውስብስብነት
ዝቅተኛ
Высокая
Высокая

*AccelStor NeoSapphire™ አሁንም ሁሉም ፍላሽ ድርድር ነው፣ ይህም በትርጉሙ “3 kopecks” አያስከፍልም፣ በተለይም ባለ ሁለት አቅም ክምችት ስላለው። ሆኖም ግን, በእሱ ላይ የተመሰረተ የመፍትሄውን የመጨረሻ ዋጋ ከሌሎች ሻጮች ተመሳሳይ ከሆኑ ጋር ሲወዳደር ዋጋው ዝቅተኛ ነው ተብሎ ሊወሰድ ይችላል.

የመተግበሪያ አገልጋዮችን እና ሁሉም የፍላሽ ድርድር ኖዶችን ለማገናኘት ቶፖሎጂ ይህንን ይመስላል።

Oracle RAC እና AcelStor Shared-Nothing architecture ላይ የተመሰረተ ስህተትን የሚቋቋም መፍትሄ መገንባት

ቶፖሎጂን በሚያቅዱበት ጊዜ፣ የአስተዳደር ማብሪያና ማጥፊያዎችን ማባዛት እና አገልጋዮችን ማገናኘት በጣም ይመከራል።

እዚህ እና በመቀጠል በፋይበር ቻናል ስለመገናኘት እንነጋገራለን. iSCSI ን ከተጠቀሙ፣ ሁሉም ነገር ተመሳሳይ ይሆናል፣ ጥቅም ላይ ለሚውሉ የመቀየሪያ አይነቶች የተስተካከለ እና ትንሽ ለየት ያለ የአደራደር ቅንጅቶች።

በድርድር ላይ የዝግጅት ስራ

ያገለገሉ መሳሪያዎች እና ሶፍትዌሮች

የአገልጋይ እና የመቀየሪያ ዝርዝሮች

ክፍለ አካላት
መግለጫ

Oracle ዳታቤዝ 11g አገልጋዮች
ሁለት

የአገልጋይ ስርዓተ ክወና
Oracle Linux

Oracle የውሂብ ጎታ ስሪት
11 ግ (RAC)

ፕሮሰሰሮች በአገልጋይ
ሁለት 16 ኮር Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz

አካላዊ ማህደረ ትውስታ በአገልጋይ
128GB

FC አውታረ መረብ
16Gb/s FC ከብዙ መንገድ ጋር

FC HBA
Emulex Lpe-16002B

ለክላስተር አስተዳደር የወሰኑ የህዝብ 1GbE ወደቦች
ኢንቴል ኢተርኔት አስማሚ RJ45

16Gb/s FC መቀየሪያ
6505 እ.ኤ.አ.

ለውሂብ ማመሳሰል የወሰኑ የግል 10GbE ወደቦች
Intel X520

AcelStor NeoSapphire™ ሁሉም የፍላሽ አደራደር መግለጫ

ክፍለ አካላት
መግለጫ

የማጠራቀሚያ ስርዓት
NeoSapphire™ ከፍተኛ ተገኝነት ሞዴል፡ H710

የምስል ሥሪት
4.0.1

ጠቅላላ የድራይቮች ብዛት
48

የማሽከርከር መጠን
1.92TB

የ Drive አይነት
ኤስኤስዲ

FC ኢላማ ወደቦች
16 x 16Gb ወደቦች (8 በአንድ መስቀለኛ መንገድ)

የአስተዳደር ወደቦች
በኤተርኔት መቀየሪያ በኩል ወደ አስተናጋጆች የሚገናኘው 1GbE የኤተርኔት ገመድ

የልብ ምት ወደብ
በሁለት የማከማቻ ኖዶች መካከል ያለው የ1GbE ኤተርኔት ገመድ

የውሂብ ማመሳሰል ወደብ
56Gb/s InfiniBand ገመድ

ድርድር ከመጠቀምዎ በፊት ማስጀመር አለብዎት። በነባሪ, የሁለቱም አንጓዎች የቁጥጥር አድራሻ አንድ ነው (192.168.1.1). ከእነሱ ጋር አንድ በአንድ መገናኘት እና አዲስ (ቀድሞውኑ የተለየ) የአስተዳደር አድራሻዎችን ማዘጋጀት እና የጊዜ ማመሳሰልን ማዘጋጀት ያስፈልግዎታል, ከዚያ በኋላ የማኔጅመንት ወደቦች ከአንድ አውታረ መረብ ጋር ሊገናኙ ይችላሉ. ከዚያ በኋላ፣ አንጓዎቹ ለኢንተርሊንክ ግንኙነቶች ንዑስ መረቦችን በመመደብ ወደ HA ጥንድ ይጣመራሉ።

Oracle RAC እና AcelStor Shared-Nothing architecture ላይ የተመሰረተ ስህተትን የሚቋቋም መፍትሄ መገንባት

ማስጀመር ከተጠናቀቀ በኋላ ድርድርን ከማንኛውም መስቀለኛ መንገድ ማስተዳደር ይችላሉ።

በመቀጠል አስፈላጊዎቹን ጥራዞች እንፈጥራለን እና ወደ መተግበሪያ አገልጋዮች እናተምታቸዋለን.

Oracle RAC እና AcelStor Shared-Nothing architecture ላይ የተመሰረተ ስህተትን የሚቋቋም መፍትሄ መገንባት

ለ Oracle ASM ብዙ ጥራዞችን ለመፍጠር በጣም ይመከራል ምክንያቱም ይህ የአገልጋዮቹን ኢላማዎች ቁጥር ስለሚጨምር በመጨረሻም አጠቃላይ አፈፃፀምን ያሻሽላል (በሌላ ወረፋ ላይ የበለጠ ጽሑፍ).

የሙከራ ውቅር

የማከማቻ መጠን ስም
የድምፅ መጠን

መረጃ 01
200GB

መረጃ 02
200GB

መረጃ 03
200GB

መረጃ 04
200GB

መረጃ 05
200GB

መረጃ 06
200GB

መረጃ 07
200GB

መረጃ 08
200GB

መረጃ 09
200GB

መረጃ 10
200GB

ፍርግርግ01
1GB

ፍርግርግ02
1GB

ፍርግርግ03
1GB

ፍርግርግ04
1GB

ፍርግርግ05
1GB

ፍርግርግ06
1GB

ድገም01
100GB

ድገም02
100GB

ድገም03
100GB

ድገም04
100GB

ድገም05
100GB

ድገም06
100GB

ድገም07
100GB

ድገም08
100GB

ድገም09
100GB

ድገም10
100GB

ስለ ድርድሩ አሠራር እና በድንገተኛ ሁኔታዎች ውስጥ ስለሚከሰቱ ሂደቶች አንዳንድ ማብራሪያዎች

Oracle RAC እና AcelStor Shared-Nothing architecture ላይ የተመሰረተ ስህተትን የሚቋቋም መፍትሄ መገንባት

የእያንዳንዱ መስቀለኛ መንገድ የውሂብ ስብስብ "ስሪት ቁጥር" መለኪያ አለው. ከመጀመሪያው ጅምር በኋላ, ተመሳሳይ እና እኩል ነው 1. በሆነ ምክንያት የስሪት ቁጥሩ የተለየ ከሆነ, ውሂብ ሁልጊዜ ከአሮጌው ስሪት ወደ ታናሹ ይመሳሰላል, ከዚያ በኋላ የወጣት ቁጥር ቁጥር ይጣጣማል, ማለትም. ይህ ማለት ቅጂዎቹ ተመሳሳይ ናቸው ማለት ነው. ስሪቶች የተለያዩ ሊሆኑ የሚችሉበት ምክንያቶች

  • የአንዱን አንጓዎች ዳግም ማስጀመር መርሐግብር ተይዞለታል
  • በድንገት መዘጋት (የኃይል አቅርቦት, ሙቀት, ወዘተ) በአንደኛው መስቀለኛ መንገድ ላይ አደጋ.
  • የጠፋው የ InfiniBand ግንኙነት ማመሳሰል አለመቻል
  • በመረጃ መበላሸት ምክንያት በአንዱ አንጓዎች ላይ ብልሽት። እዚህ አዲስ የ HA ቡድን መፍጠር እና የውሂብ ስብስቡን ማመሳሰል ያስፈልግዎታል.

ለማንኛውም በመስመር ላይ የሚቀረው መስቀለኛ መንገድ ከጥንዶቹ ጋር ያለው ግንኙነት ከተመለሰ በኋላ የውሂብ ስብስቡን ለማመሳሰል የስሪት ቁጥሩን በአንድ ይጨምራል።

በኤተርኔት ማገናኛ ላይ ያለው ግንኙነት ከጠፋ፣ Heartbeat ለጊዜው ወደ InfiniBand ይቀየራል እና ወደነበረበት ሲመለስ በ10 ሰከንድ ውስጥ ይመለሳል።

አስተናጋጆችን በማዘጋጀት ላይ

የስህተት መቻቻልን ለማረጋገጥ እና አፈፃፀሙን ለማሻሻል የMPIO ድጋፍን ለድርድር ማንቃት አለቦት። ይህንን ለማድረግ መስመሮችን ወደ /etc/multipath.conf ፋይል ማከል እና ከዚያ የመልቲ መንገድ አገልግሎትን እንደገና ማስጀመር ያስፈልግዎታል

የተደበቀ ጽሑፍመሳሪያዎች {
መሳሪያ {
ሻጭ "AStor"
የመንገድ_ቡድን_ፖሊሲ "ቡድን_በፕሪዮ"
ዱካ_መራጭ "ወረፋ-ርዝመት 0"
ዱካ አራሚ "ቱር"
ባህሪያት "0"
የሃርድዌር_ተቆጣጣሪ "0"
prio "const"
አለመሳካት ወዲያውኑ
ፈጣን_io_fail_tmo 5
dev_loss_tmo 60
የተጠቃሚ_ተስማሚ_ስሞች አዎ
አግኝ_prio አዎ
Rr_min_io_rq 1
ምንም_ዱካ_እንደገና ይሞክሩ 0
}
}

በመቀጠል ASM ከMPIO ጋር በ ASMLib በኩል እንዲሰራ የ/etc/sysconfig/oracleasm ፋይሉን መቀየር እና ከዚያ /etc/init.d/oracleasm scandisks ን ማስኬድ ያስፈልግዎታል

የተደበቀ ጽሑፍ

# ORACLEASM_SCANORDER፡ የዲስክ ቅኝትን ለማዘዝ የሚዛመዱ ቅጦች
ORACLEASM_SCANORDER="dm"

# ORACLEASM_SCANEXCLUDE፡ ዲስኮችን ከስካን ለማግለል ከስርዓተ-ጥለት ጋር የሚዛመዱ
ORACLEASM_SCANEXCLUDE="sd"

አመለከተ

ASMLibን መጠቀም ካልፈለጉ፣ የ UDEV ደንቦችን መጠቀም ይችላሉ፣ ይህም ለASMLib መሰረት ነው።

ከኦራክል ዳታቤዝ ስሪት 12.1.0.2 ጀምሮ፣ አማራጩ እንደ ASMFD ሶፍትዌር አካል ሆኖ ለመጫን ይገኛል።

ለ Oracle ASM የተፈጠሩት ዲስኮች ድርድር በአካል ከሚሠራው (4K) ጋር የተጣጣሙ መሆናቸውን ማረጋገጥ አስፈላጊ ነው። አለበለዚያ የአፈፃፀም ችግሮች ሊከሰቱ ይችላሉ. ስለዚህ ፣ ከተገቢው መመዘኛዎች ጋር መጠኖችን መፍጠር አስፈላጊ ነው-

የተከፈለ /dev/ካርታ/የመሳሪያ-ስም mklabel gpt mkpart አንደኛ ደረጃ 2048s 100% አሰላለፍ-ቼክ ምርጥ 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

ፍርግርግ01
1GB
ድግግሞሽ፡ መደበኛ
ስም፡ DGGRID1
ዓላማ፡ ፍርግርግ፡ CRS እና ድምጽ መስጠት

4MB

ፍርግርግ02
1GB

ፍርግርግ03
1GB

ፍርግርግ04
1GB
ድግግሞሽ፡ መደበኛ
ስም፡ DGGRID2
ዓላማ፡ ፍርግርግ፡ CRS እና ድምጽ መስጠት

4MB

ፍርግርግ05
1GB

ፍርግርግ06
1GB

ድገም01
100GB
ድግግሞሽ፡ መደበኛ
ስም፡ DGREDO1
ዓላማው፡ የክር ሎግ ድገም 1

4MB

ድገም02
100GB

ድገም03
100GB

ድገም04
100GB

ድገም05
100GB

ድገም06
100GB
ድግግሞሽ፡ መደበኛ
ስም፡ DGREDO2
ዓላማው፡ የክር ሎግ ድገም 2

4MB

ድገም07
100GB

ድገም08
100GB

ድገም09
100GB

ድገም10
100GB

የውሂብ ጎታ ቅንብሮች

  • የማገጃ መጠን = 8 ኪ
  • ስዋፕ ቦታ = 16 ጂቢ
  • ኤኤምኤም (ልሾ-ሰር የማህደረ ትውስታ አስተዳደር) አሰናክል
  • ግልጽ ግዙፍ ገጾችን አሰናክል

ሌሎች ቅንብሮች

# 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
✓ ኦራክል ለስላሳ nproc 2047
ኦራክል ሃርድ nproc 16384
✓ ኦራክል ለስላሳ ኖፋይል 1024
ኦራክል ሃርድ ኖፋይል 65536
✓ ኦራክል ለስላሳ ቁልል 10240
✓ ኦራክል ሃርድ ቁልል 32768
✓ ለስላሳ ሜምሎክ 120795954
ሃርድ ሜምሎክ 120795954

sqlplus “/ as sysdba”
የስርዓት ስብስብ ሂደቶችን መቀየር = 2000 scope = spfile;
የስርዓት ስብስብ open_cursors=2000 scope=spfile;
የስርዓት ማቀናበሪያ ክፍለ ጊዜ_cached_cursors=300 scope=spfile;
የስርዓት ስብስብ db_files = 8192 scope = spfile;

ውድቀት ፈተና

ለማሳያ ዓላማዎች፣ HammerDB የOLTP ጭነትን ለመኮረጅ ጥቅም ላይ ውሏል። HammerDB ውቅር፡

የመጋዘኖች ብዛት
256

ጠቅላላ ግብይቶች በተጠቃሚ
1000000000000

ምናባዊ ተጠቃሚዎች
256

ውጤቱም 2.1M TPM ነበር፣ ይህም ከድርድር አፈጻጸም ወሰን የራቀ ነው። H710ነገር ግን አሁን ላለው የአገልጋዮች ሃርድዌር ውቅር (በዋነኛነት በአቀነባባሪዎች ምክንያት) እና ቁጥራቸው “ጣሪያ” ነው። የዚህ ሙከራ አላማ አሁንም ቢሆን የመፍትሄውን አጠቃላይ ስህተት መቻቻል ለማሳየት እና ከፍተኛውን አፈፃፀም ለማምጣት አይደለም. ስለዚህ, በዚህ ቁጥር ላይ በቀላሉ እንገነባለን.

Oracle RAC እና AcelStor Shared-Nothing architecture ላይ የተመሰረተ ስህተትን የሚቋቋም መፍትሄ መገንባት

የአንዱን አንጓዎች ውድቀት ይሞክሩ

Oracle RAC እና AcelStor Shared-Nothing architecture ላይ የተመሰረተ ስህተትን የሚቋቋም መፍትሄ መገንባት

Oracle RAC እና AcelStor Shared-Nothing architecture ላይ የተመሰረተ ስህተትን የሚቋቋም መፍትሄ መገንባት

አስተናጋጆቹ ወደ ማከማቻው የሚወስዱትን ዱካዎች በከፊል አጥተዋል፣ በቀሪዎቹ በሁለተኛው መስቀለኛ መንገድ መስራታቸውን ቀጠሉ። በድጋሚ በተገነቡት መንገዶች ምክንያት አፈጻጸሙ ለጥቂት ሰከንዶች ቀንሷል፣ እና ከዚያ ወደ መደበኛው ተመልሷል። በአገልግሎት ላይ ምንም መቆራረጥ አልነበረም።

የካቢኔ ውድቀት ሙከራ ከሁሉም መሳሪያዎች ጋር

Oracle RAC እና AcelStor Shared-Nothing architecture ላይ የተመሰረተ ስህተትን የሚቋቋም መፍትሄ መገንባት

Oracle RAC እና AcelStor Shared-Nothing architecture ላይ የተመሰረተ ስህተትን የሚቋቋም መፍትሄ መገንባት

በዚህ አጋጣሚ አፈጻጸሙም በመንገዶቹ መልሶ ማዋቀር ምክንያት ለጥቂት ሰኮንዶች ወድቋል፣ እና ከዚያ ወደ መጀመሪያው እሴት ግማሽ ተመለሰ። አንድ አፕሊኬሽን ሰርቨር ከስራ በመውጣቱ ውጤቱ ከመጀመሪያው በግማሽ ቀንሷል። በአገልግሎት ላይም ምንም አይነት መቆራረጥ አልነበረም።

ስህተትን የሚታገስ የመስቀል-ራክ አደጋ መልሶ ማግኛ መፍትሔ ለኦራክል በተመጣጣኝ ወጪ እና በትንሽ የማሰማራት/የአስተዳደር ጥረት መተግበር ካስፈለገ Oracle RAC እና አርክቴክቸር አብረው ይሰራሉ። AcelStor የተጋራ-ምንም ከምርጥ አማራጮች ውስጥ አንዱ ይሆናል. ከOracle RAC ይልቅ፣ ክላስተር፣ ተመሳሳይ ዲቢኤምኤስ ወይም ቨርቹዋልላይዜሽን ሲስተምስ፣ ለምሳሌ የሚያቀርብ ሌላ ሶፍትዌር ሊኖር ይችላል። መፍትሄውን የመገንባት መርህ አንድ አይነት ሆኖ ይቆያል. እና የታችኛው መስመር ለ RTO እና RPO ዜሮ ነው.

ምንጭ: hab.com

አስተያየት ያክሉ