בניית פתרון סובלני לתקלות המבוסס על ארכיטקטורת Oracle RAC ו-AccelStor Shared-Nothing

למספר ניכר של יישומים ארגוניים ומערכות וירטואליזציה יש מנגנונים משלהם לבניית פתרונות סובלני תקלות. באופן ספציפי, Oracle RAC (Oracle Real Application Cluster) הוא אשכול של שני שרתי מסד נתונים או יותר של Oracle הפועלים יחד כדי לאזן עומס ולספק סובלנות לתקלות ברמת השרת/יישום. כדי לעבוד במצב זה, אתה צריך אחסון משותף, שהוא בדרך כלל מערכת אחסון.

כפי שכבר דנו באחד משלנו מאמרים, למערכת האחסון עצמה, למרות נוכחותם של רכיבים משוכפלים (כולל בקרים), עדיין יש נקודות כשל - בעיקר בצורה של סט נתונים בודדים. לכן, כדי לבנות פתרון של Oracle עם דרישות אמינות מוגברות, ערכת "N שרתים - מערכת אחסון אחת" צריכה להיות מסובכת.

ראשית, כמובן, עלינו להחליט בפני אילו סיכונים אנו מנסים לבטח. במאמר זה, לא נשקול הגנה מפני איומים כמו "הגיע מטאוריט". אז בניית פתרון התאוששות מאסון מפוזר גיאוגרפית תישאר נושא לאחד מהמאמרים הבאים. כאן נסתכל על מה שנקרא Cross-Rack התאוששות מאסון, כאשר ההגנה נבנית ברמת ארונות השרת. הארונות עצמם יכולים להיות ממוקמים באותו חדר או בחדרים שונים, אך לרוב בתוך אותו בניין.

ארונות אלו חייבים להכיל את כל מערך הציוד והתוכנה הנדרשים שיאפשרו את פעולתם של מסדי נתונים של אורקל ללא קשר למצבו של "השכן". במילים אחרות, באמצעות פתרון התאוששות מאסון Cross-Rack, אנו מבטלים את הסיכונים לכישלון:

• שרתי אפליקציות של אורקל
• מערכות אחסון
• החלפת מערכות
• כשל מוחלט של כל הציוד בארון:
  • הפסקת חשמל
  • כשל במערכת הקירור
  • גורמים חיצוניים (אדם, טבע וכו')

שכפול שרתי אורקל מרמז על עיקרון הפעולה של Oracle RAC והוא מיושם באמצעות אפליקציה. גם שכפול מתקני מיתוג אינו מהווה בעיה. אבל עם שכפול של מערכת האחסון, הכל לא כל כך פשוט.

האפשרות הפשוטה ביותר היא שכפול נתונים ממערכת האחסון הראשית למערכת הגיבוי. סינכרוני או אסינכרוני, בהתאם ליכולות מערכת האחסון. עם שכפול אסינכרוני, עולה מיד השאלה של הבטחת עקביות נתונים ביחס לאורקל. אך גם אם יש אינטגרציה של תוכנה עם האפליקציה, בכל מקרה, במקרה של תקלה במערכת האחסון הראשית, תידרש התערבות ידנית של מנהלים על מנת להעביר את האשכול לאחסון גיבוי.

אפשרות מורכבת יותר היא "וירטואליזרים" לאחסון תוכנה ו/או חומרה שיבטלו בעיות עקביות והתערבות ידנית. אבל המורכבות של הפריסה והניהול שלאחר מכן, כמו גם העלות המגונה מאוד של פתרונות כאלה, מפחידה רבים.

פתרון מערך ה-AccelStor NeoSapphire™ All Flash מושלם עבור תרחישים כמו התאוששות מאסון Cross-Rack H710 באמצעות ארכיטקטורת Shared-Nothing. דגם זה הוא מערכת אחסון דו-צמתים המשתמשת בטכנולוגיית FlexiRemap® קניינית לעבודה עם כונני הבזק. הודות ל FlexiRemap® NeoSapphire™ H710 מסוגל לספק ביצועים של עד 600K IOPS@4K כתיבה אקראית וקריאה אקראית של 1M+ IOPS@4K, דבר שאינו ניתן להשגה בעת שימוש במערכות אחסון קלאסיות מבוססות RAID.

אבל המאפיין העיקרי של NeoSapphire™ H710 הוא ביצוע של שני צמתים בצורה של מקרים נפרדים, שלכל אחד מהם יש עותק משלו של הנתונים. סנכרון של צמתים מתבצע דרך ממשק InfiniBand החיצוני. הודות לארכיטקטורה זו, ניתן להפיץ צמתים למיקומים שונים במרחק של עד 100 מטר, ובכך לספק פתרון לשחזור מאסון Cross-Rack. שני הצמתים פועלים באופן סינכרוני לחלוטין. מהצד המארח, ה-H710 נראה כמו מערכת אחסון כפולה רגילה. לכן, אין צורך לבצע אפשרויות תוכנה או חומרה נוספות או הגדרות מורכבות במיוחד.

אם נשווה את כל פתרונות התאוששות מאסון Cross-Rack שתוארו לעיל, האפשרות של AccelStor בולטת באופן ניכר מהשאר:

AccelStor NeoSapphire™ Shared Nothing Architecture
מערכת אחסון "וירטואליזטור" של תוכנה או חומרה
פתרון מבוסס שכפול

זמינות

כשל בשרת
אין זמן השבתה
אין זמן השבתה
אין זמן השבתה

כשל במתג
אין זמן השבתה
אין זמן השבתה
אין זמן השבתה

כשל במערכת האחסון
אין זמן השבתה
אין זמן השבתה
זמן השבתה

כשל ארון שלם
אין זמן השבתה
אין זמן השבתה
זמן השבתה

עלות ומורכבות

עלות פתרון
נָמוּך*
גבוה
גבוה

מורכבות הפריסה
נמוך
גבוה
גבוה

*AccelStor NeoSapphire™ הוא עדיין מערך All Flash, שבהגדרתו אינו עולה "3 קופיקות", במיוחד מכיוון שיש לו רזרבת קיבולת כפולה. עם זאת, כאשר משווים את העלות הסופית של פתרון המבוסס עליו עם עלות דומות של ספקים אחרים, העלות יכולה להיחשב לנמוכה.

הטופולוגיה לחיבור שרתי יישומים וצמתים של כל מערך Flash תיראה כך:

בעת תכנון הטופולוגיה, מומלץ מאוד גם לשכפל מתגי ניהול ולהתחבר בין שרתים.

כאן ובהמשך נדבר על חיבור דרך Fibre Channel. אם אתה משתמש ב-iSCSI, הכל יהיה זהה, מותאם לסוגי המתגים שבהם נעשה שימוש והגדרות מערך מעט שונות.

עבודת הכנה על המערך

ציוד ותוכנה בשימוש

מפרטי שרת ומתג

רכיבים
תיאור

שרתי Oracle Database 11g
שניים

מערכת הפעלה שרת
אורקל לינוקס

גרסת מסד הנתונים של אורקל
11 גרם (RAC)

מעבדים לכל שרת
שני 16 ליבות Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz

זיכרון פיזי לכל שרת
128GB

רשת FC
16Gb/s FC עם ריבוי נתיבים

FC HBA
Emulex Lpe-16002B

יציאות 1GbE ציבוריות ייעודיות לניהול אשכולות
מתאם Ethernet RJ45 של אינטל

מתג FC 16Gb/s
ברוקד 6505

יציאות 10GbE פרטיות ייעודיות לסנכרון נתונים
אינטל X520

AccelStor NeoSapphire™ מפרט מערך פלאש

רכיבים
תיאור

מערכת אחסון
NeoSapphire™ דגם זמינות גבוהה: H710

גרסת תמונה
4.0.1

מספר כולל של כוננים
48

גודל כונן
1.92TB

סוג כונן
SSD

יציאות יעד של FC
יציאות 16x 16Gb (8 לכל צומת)

יציאות ניהול
כבל Ethernet 1GbE המתחבר למארחים באמצעות מתג Ethernet

יציאת פעימות לב
כבל Ethernet 1GbE המחבר בין שני צמתי אחסון

יציאת סנכרון נתונים
כבל InfiniBand 56Gb/s

לפני שתוכל להשתמש במערך, עליך לאתחל אותו. כברירת מחדל, כתובת הבקרה של שני הצמתים זהה (192.168.1.1). צריך להתחבר אליהם אחד אחד ולהגדיר כתובות ניהול חדשות (שונות כבר) ולהגדיר סנכרון זמן, שלאחר מכן ניתן לחבר את יציאות הניהול לרשת אחת. לאחר מכן, הצמתים משולבים לזוג HA על ידי הקצאת רשתות משנה לחיבורי Interlink.

לאחר השלמת האתחול, תוכל לנהל את המערך מכל צומת.

לאחר מכן, אנו יוצרים את אמצעי האחסון הדרושים ומפרסמים אותם לשרתי יישומים.

מומלץ מאוד ליצור נפחים מרובים עבור 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 חדשה ולסנכרון מלא של מערך הנתונים.

בכל מקרה, הצומת שנשאר מקוון מגדיל את מספר הגרסה שלו באחד על מנת לסנכרן את מערך הנתונים שלו לאחר שחזור החיבור עם הזוג.

אם החיבור דרך קישור ה-Ethernet אבד, Heartbeat עובר באופן זמני ל-InfiniBand וחוזר חזרה תוך 10 שניות כאשר הוא משוחזר.

הגדרת מארחים

כדי להבטיח סובלנות תקלות ולשפר את הביצועים, עליך להפעיל תמיכת MPIO עבור המערך. לשם כך, עליך להוסיף שורות לקובץ /etc/multipath.conf, ולאחר מכן להפעיל מחדש את שירות multipath

טקסט נסתרמכשירים {
התקן {
הספק "AStor"
path_grouping_policy "group_by_prio"
path_selector "אורך תור 0"
path_checker "טור"
כולל "0"
hardware_handler "0"
פריו "קונסט"
כשל חוזר מיידי
fast_io_fail_tmo 5
dev_loss_tmo 60
שמות_ידידותיים למשתמש כן
detect_prio כן
rr_min_io_rq 1
no_path_retry 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 של Oracle Database, האפשרות זמינה להתקנה כחלק מתוכנת ASMFD.

הכרחי לוודא שהדיסקים שנוצרו עבור Oracle ASM מיושרים עם גודל הבלוק שהמערך פועל איתו פיזית (4K). אחרת, עלולות להתרחש בעיות בביצועים. לכן, יש צורך ליצור אמצעי אחסון עם הפרמטרים המתאימים:

parted /dev/mapper/device-name mklabel gpt mkpart primary 2048s 100% align-check optimal 1

הפצה של מסדי נתונים על פני אמצעי אחסון שנוצרו עבור תצורת הבדיקה שלנו

שם נפח אחסון
גודל נפח
מיפוי LUN של נפח
פירוט מכשיר ASM Volume
גודל יחידת הקצאה

נתונים 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.shmal 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 # אל תגדיר זאת אם אתה משתמש ב-Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000

# vi /etc/security/limits.conf
✓ רשת soft nproc 2047
✓ רשת קשה nproc 16384
✓ רשת soft nofile 1024
✓ grid hard nofile 65536
✓ מחסנית רכה רשת 10240
✓ מחסנית רשת קשה 32768
✓ oracle soft nproc 2047
✓ oracle hard nproc 16384
✓ oracle soft nofile 1024
✓ oracle hard nofile 65536
✓ אורקל soft stack 10240
✓ oracle hard stack 32768
✓ מלוק רך 120795954
✓ מלוק קשיח 120795954

sqlplus "/ as sysdba"
שינוי מערכת תהליכים=2000 scope=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, שהוא רחוק ממגבלת הביצועים של המערך H710, אך מהווה "תקרה" לתצורת החומרה הנוכחית של שרתים (בעיקר בשל מעבדים) ומספרם. מטרת בדיקה זו היא עדיין להדגים את סבילות התקלות של הפתרון בכללותו, ולא להשיג ביצועים מקסימליים. לכן, פשוט נבנה על הנתון הזה.

בדיקת כשל של אחד הצמתים

המארחים איבדו חלק מהנתיבים לאחסון, והמשיכו לעבוד דרך הנתיבים הנותרים עם הצומת השני. הביצועים ירדו לכמה שניות עקב בנייה מחדש של השבילים, ולאחר מכן חזרו לקדמותם. לא הייתה הפרעה בשירות.

בדיקת כשל בארון עם כל הציוד

במקרה זה, גם הביצועים ירדו לכמה שניות עקב ארגון מחדש של הנתיבים, ולאחר מכן חזרו למחצית מהערך המקורי. התוצאה הצטמצמה בחצי מהתוצאה הראשונית עקב אי הכללתו של שרת יישומים אחד מפעילות. גם בשירות לא הייתה הפרעה.

אם יש צורך ליישם פתרון שחזור מאסון Cross-Rack סובלני לתקלות עבור אורקל בעלות סבירה ועם מעט מאמץ פריסה/ניהול, אז Oracle RAC והארכיטקטורה עובדים יחד AccelStor Shared-Nothing תהיה אחת האפשרויות הטובות ביותר. במקום Oracle RAC, יכולה להיות כל תוכנה אחרת שמספקת אשכולות, אותם DBMS או מערכות וירטואליזציה, למשל. עקרון בניית הפתרון יישאר זהה. והשורה התחתונה היא אפס עבור RTO ו-RPO.

מקור: www.habr.com