สถาปัตยกรรมสำหรับ MySQL ที่พร้อมใช้งานสูงพร้อมการล้มเหลวอัตโนมัติในสถานที่ที่มีความหลากหลายทางกายภาพ


19

ฉันได้ค้นคว้าวิธีแก้ปัญหาความพร้อมใช้งานสูง (HA) สำหรับ MySQL ระหว่างศูนย์ข้อมูล

สำหรับเซิร์ฟเวอร์ที่ตั้งอยู่ในสภาพแวดล้อมทางกายภาพเดียวกันฉันต้องการคู่หลักที่มี heartbeat (วีไอพีลอย) โดยใช้วิธีการใช้งานแบบพาสซีฟ Heartbeat มีทั้งการเชื่อมต่อแบบอนุกรมและการเชื่อมต่ออีเธอร์เน็ต

ในที่สุดเป้าหมายของฉันคือการรักษาระดับความพร้อมใช้งานไว้เท่าเดิม แต่ระหว่างศูนย์ข้อมูล ฉันต้องการล้มเหลวแบบไดนามิกระหว่างศูนย์ข้อมูลทั้งสองโดยไม่มีการแทรกแซงด้วยตนเองและยังคงรักษาความสมบูรณ์ของข้อมูล

จะมี BGP อยู่ด้านบน กลุ่มเว็บในสถานที่ทั้งสองซึ่งจะมีศักยภาพในการกำหนดเส้นทางไปยังฐานข้อมูลระหว่างทั้งสองฝ่าย หากการเชื่อมต่ออินเทอร์เน็ตลงไปที่ไซต์ 1 ลูกค้าจะกำหนดเส้นทางผ่านไซต์ 2 ไปยังเว็บคลัสเตอร์จากนั้นไปยังฐานข้อมูลในไซต์ 1 หากลิงก์ระหว่างไซต์ทั้งสองยังคงทำงานอยู่

กับสถานการณ์นี้เนื่องจากการขาดการเชื่อมโยงทางกายภาพ (ต่อเนื่อง) มีโอกาสมากขึ้นที่จะแยกสมอง หาก WAN ลงไประหว่างทั้งสองไซต์ VIP จะลงเอยที่ทั้งสองเว็บไซต์

ปัญหาที่อาจเกิดขึ้นอีกประการหนึ่งที่ฉันเห็นคือความยากในการปรับโครงสร้างพื้นฐานนี้ไปยังศูนย์ข้อมูลที่สามในอนาคต

เลเยอร์เครือข่ายไม่ได้มุ่งเน้น สถาปัตยกรรมมีความยืดหยุ่นในขั้นตอนนี้ อีกครั้งฉันมุ่งเน้นเป็นวิธีการในการรักษาความสมบูรณ์ของข้อมูลเช่นเดียวกับความล้มเหลวอัตโนมัติกับฐานข้อมูล MySQL ฉันน่าจะออกแบบส่วนที่เหลือรอบนี้

คุณสามารถแนะนำโซลูชันที่พิสูจน์แล้วสำหรับ MySQL HA ระหว่างไซต์ที่มีความหลากหลายทางกายภาพสองไซต์

ขอบคุณที่สละเวลาอ่านข้อความนี้ ฉันหวังว่าจะอ่านคำแนะนำของคุณ


1
สวัสดี - คุณได้กำหนดแนวทางหรือยัง? มันจะน่าสนใจที่จะได้ยินสิ่งที่คุณตัดสินใจที่จะทำ เรามีปัญหาเดียวกัน
Martin

ฉันขอขอบคุณคำตอบและเวลาของทุกคน น่าเสียดายที่คำตอบเหล่านี้ไม่ได้ตอบโจทย์รากของคำถามอย่างแท้จริงซึ่งเป็นวิธีที่ผู้คนสามารถแก้ไขคำถามได้สำเร็จในสภาพแวดล้อมการผลิต เมื่อฉันมาถึงข้อสรุปที่นี่ฉันจะมั่นใจที่จะแบ่งปันความคิดสุดท้ายของฉัน จนถึงขณะนี้สิ่งนี้ดูเหมือนจะเป็นข้อ จำกัด ที่รุนแรงกับความสามารถของ MySQL ในการขยาย
วอร์เนอร์

บางทีคุณอาจไม่ได้วิธีการเขียนเพราะคุณถามคำถามผิดหรือเปล่า? ข้อมูลใดที่คุณต้องการทำซ้ำและทำไม เมื่อคุณเริ่มถามคำถามเหล่านี้คุณจะสามารถค้นหาสาเหตุที่คุณต้องการจำลองแบบได้ตั้งแต่แรก สมองแยกไม่ได้เป็นเพียงปัญหา MySQL แต่เป็นแนวคิดของคลัสเตอร์
The Unix Janitor

คำตอบที่ฉันให้ไว้ในที่นี้รวมถึงข้อมูลเพิ่มเติมบางอย่าง: serverfault.com/questions/142683/ … ฉันจะจัดให้มีการติดตามเมื่อมีการใช้งานจริงขั้นสุดท้าย
วอร์เนอร์

คำตอบ:


9

คุณจะเผชิญกับปัญหาทฤษฎีบท "CAP" คุณไม่สามารถมีความสอดคล้องความพร้อมใช้งานและความทนทานต่อพาร์ติชันในเวลาเดียวกัน

DRBD / MySQL HA อาศัยการจำลองแบบซิงโครนัสที่ระดับอุปกรณ์บล็อก สิ่งนี้ใช้ได้ในขณะที่ทั้งสองโหนดพร้อมใช้งานหรือหากมีความผิดปกติเกิดขึ้นอีกครั้งก็จะทำการรีบูทและจากนั้นกลับมาอีกครั้ง ปัญหาเริ่มต้นเมื่อคุณได้รับพาร์ติชันเครือข่าย

พาร์ติชันเครือข่ายมีแนวโน้มอย่างมากเมื่อคุณเรียกใช้ที่สองศูนย์ข้อมูล โดยพื้นฐานแล้วฝ่ายใดฝ่ายหนึ่งไม่สามารถแยกพาร์ติชันจากโหนดอื่นล้มเหลว โหนดรองไม่ทราบว่าควรใช้เวลาหรือไม่ (โหนดหลักล้มเหลว) หรือไม่ (ลิงก์หายไป)

ในขณะที่เครื่องของคุณอยู่ในตำแหน่งเดียวกันคุณสามารถเพิ่มช่องทางที่สองของการสื่อสาร (โดยทั่วไปคือสายเคเบิลอนุกรมหรืออีเธอร์เน็ตแบบไขว้) เพื่อแก้ไขปัญหานี้ - ดังนั้นอุปกรณ์รองรู้ว่าเมื่อตัวหลักเป็นของแท้และไม่ใช่พาร์ติชันเครือข่าย .


ปัญหาต่อไปคือประสิทธิภาพ ในขณะที่ DRBD สามารถให้ประสิทธิภาพการทำงานที่ดี ** เมื่อเครื่องของคุณมีการเชื่อมต่อที่มีความหน่วงต่ำ (เช่นกิกะบิตอีเธอร์เน็ต - แต่บางคนใช้เครือข่ายความเร็วสูงโดยเฉพาะ) ยิ่งเวลาแฝงเครือข่ายมากเท่าไหร่ . นี่เป็นเพราะมันต้องรอเซิร์ฟเวอร์รอง (เมื่อออนไลน์) เพื่อยอมรับการเขียนทั้งหมดก่อนที่จะพูดว่า "ตกลง" กับแอปเพื่อให้แน่ใจว่าการเขียนมีความทนทาน

หากคุณทำสิ่งนี้ในดาต้าเซ็นเตอร์ที่แตกต่างกันโดยทั่วไปคุณจะมีเวลาแฝงอีกหลายมิลลิวินาทีแม้ว่าจะอยู่ใกล้กันก็ตาม

** ยังช้ากว่าคอนโทรลเลอร์ IO ในเครื่องที่เหมาะสม

*** คุณไม่สามารถใช้ MyISAM สำหรับระบบ DRBD ที่มีความพร้อมใช้งานสูงเนื่องจากไม่สามารถกู้คืนได้อย่างถูกต้อง / โดยอัตโนมัติจากการปิดระบบที่ไม่สะอาดซึ่งจำเป็นในระหว่างการล้มเหลว


ฉันขอขอบคุณเวลาและความคิดของคุณ คุณอธิบายถึงปัญหาบางอย่างที่ฉันพยายามหลีกเลี่ยงได้เป็นอย่างดี เป็นการดีที่ฉันต้องการเก็บข้อดีของการใช้งานคู่แบบพาสซีฟ / แบบพาสซีฟสำหรับการบำรุงรักษาและการล้มเหลวอย่างรวดเร็วในขณะที่ลดความเสี่ยงจากความเสียหายของข้อมูล ฉันคิดว่าบางคนที่นั่นพบวิธีแก้ปัญหาที่ยอมรับได้
วอร์เนอร์

1
จริง ข้อมูลไม่ต้องการเป็นสองสถานที่ในครั้งเดียว
Matt Simmons

3

สิ่งที่เกี่ยวกับการใช้ VLAN เพื่อผูกเซิร์ฟเวอร์ทั้งหมดที่ศูนย์ข้อมูลสองแห่ง (หรือมากกว่า) เข้าด้วยกัน จากนั้นคุณสามารถใช้ CARP สำหรับการเฟลโอเวอร์อัตโนมัติ ใช้การจำลองแบบฐานข้อมูลเพื่อให้ทุกอย่างสอดคล้องกัน

หากคุณเป็นเจ้าของศูนย์ข้อมูลคุณสามารถมั่นใจได้ว่าศูนย์ข้อมูลแต่ละแห่งมีอัปลิงค์ WAN หลายรายการ


นั่นเป็นความคิดแรกของฉัน การแนะนำเลเยอร์ 2 ถึงระดับนั้นจะต้องใช้วิธีการจากบนลงล่างระหว่างเว็บไซต์ทั้งสอง บทบาทเซิร์ฟเวอร์อื่นที่มีความซ้ำซ้อนโดยใช้ LinuxHA จะต้องมีการนำไปใช้ที่คล้ายกันเช่นไฟร์วอลล์ มิฉะนั้นจะมีปัญหาการกำหนดเส้นทาง ในที่สุดแม้ว่าจะมีอัปลิงค์ WAN หลายแห่งระหว่างทั้งสองไซต์ระดับความสะดวกสบายของฉันลดลงอย่างมากเมื่อเทียบกับทั้งอัปเกรดอนุกรมและอีเธอร์เน็ต มันมีความเสี่ยงมากกว่าที่ฉันจะทนได้ ยิ่งกว่านั้นดูเหมือนว่าควรจะมีทางออกที่ดีกว่า
Warner

3

ขั้นตอนแรกของคุณควรจะอัพเกรดโซลูชั่น HA ปัจจุบันของคุณเป็นระดับที่ใช้ OpenAIS เป็นเลเยอร์สมาชิกคลัสเตอร์: สิ่งนี้จะช่วยให้คุณมีความยืดหยุ่นมากและมีการเชื่อมโยงเวลาแฝงที่ต่ำระหว่างไซต์ต่างๆ PaceMaker และ RHEL Clustering สนับสนุนสิ่งนี้

สำหรับการล้มเหลวของศูนย์ข้อมูลอัตโนมัติคุณต้องมีไซต์ที่สามเพื่อทำหน้าที่เป็น tie-breaker มิฉะนั้นไซต์ของคุณจะไม่สามารถแยกแยะระหว่างปัญหาการกำหนดเส้นทางระหว่างไซต์และความล้มเหลวของไซต์ระยะไกล Microsoft มีเว็บคาสต์ที่ดีอย่างน่าประหลาดใจที่ครอบคลุมพื้นที่:

Windows Server 2008 การทำคลัสเตอร์หลายไซต์

แน่นอนว่าเทคโนโลยีที่แน่นอนไม่ได้จับคู่กับโดเมน Linux แต่แนวคิดก็เหมือนกัน


1

ขออภัยนี่เป็นอีกเครือข่ายหนึ่ง แต่เป็นความคิดที่ดีสำหรับคุณ ...

สำหรับสถานการณ์สมองแตกที่คุณพูดถึงคุณอาจมีลิงก์ซ้ำซ้อนระหว่างไซต์สองแห่งเพื่อลดโอกาสที่จะเกิดเหตุการณ์เช่นนี้


ฉันจะกลับไปกลับมาในเรื่องนั้น ก่อนอื่นฉันเขียนมันออกไปโดยสิ้นเชิงว่ามันเสี่ยงเกินไป ตอนนี้ฉันกำลังพิจารณา ความเสี่ยงจากการเสียหายของข้อมูลที่เกิดขึ้นจริงกับสองเส้นทางที่มีความหลากหลายนั้นค่อนข้างสูง มันอยู่ในรายการสั้น ๆ ของฉันตอนนี้
วอร์เนอร์

0

โปรดทราบว่าคุณอาจไม่สามารถใช้ BGP ได้เนื่องจากบล็อกที่มีเส้นทางที่เล็กที่สุดคือ 4k, a / 22 โชคดีที่ได้รับหนึ่งบล็อก อาจจำเป็นต้องใช้โซลูชันที่อิงกับ DNS


+1 สำหรับความเป็นจริง คุณสามารถใช้บริการ DNS ที่จัดการอย่างดีเช่น UltraDNS และบริการตรวจสอบไซต์ "SiteBacker" เพื่อให้คุณได้รับประโยชน์สูงสุดจากที่นั่น
Martin

1
เรามี BGP อยู่แล้ว นี่อยู่นอกขอบเขตของคำถามของฉัน
Warner

2
ไม่บล็อกที่มีเส้นทางที่เล็กที่สุดคือ / 24 ที่จริงแล้วไม่ใช่ .. บล็อกที่สามารถกำหนดเส้นทางได้ทางร่างกายที่เล็กที่สุดคือ / 28 แต่คุณอาจถูกมองข้ามโดยทุกคน คำนำหน้าเล็กที่สุดที่จะรับฟังคือ / 24
Tom O'Connor

0

การให้คำตอบที่ถูกต้องอาจยากขึ้นอยู่กับจำนวนข้อมูลที่คุณมีจำนวนเซิร์ฟเวอร์ที่คุณต้องการให้พอดีกับสิ่งนี้เป็นต้นที่กล่าวว่าคำตอบของฉันอาจไม่ใช่หนึ่งหรืออย่างน้อยที่คุณกำลังมองหา

ไม่มีวิธีการพิสูจน์แล้วสำหรับเว็บไซต์หลายแห่งที่มี MySQL แต่มีวิธีแก้ปัญหาที่ใช้งานได้ ดังที่บางคนชี้ให้เห็นใช่ DRDB ทำงานได้ดี แต่มีข้อ จำกัด หรือปัญหาที่เป็นไปได้ขึ้นอยู่กับการตั้งค่าของคุณ

คุณต้องการไซต์ที่สาม (ดาต้าเซ็นเตอร์อื่น) ไหม ถ้าเป็นเช่นนั้นคุณต้องใช้เวลาและเงินเท่าไหร่?

พิจารณาทุกครั้งที่คุณเพิ่มเซิร์ฟเวอร์ master / slave / dns สำรองข้อมูล ... คุณเพิ่มเซิร์ฟเวอร์ของคุณเพื่อจัดการความสามารถในการจัดการของคุณในแง่ของจำนวนเซิร์ฟเวอร์คืออะไร หากคุณสามารถกำหนดหมายเลขนี้ได้คุณอาจต้องทิ้งแนวทางแก้ไขที่เป็นไปได้และดำเนินการกับสิ่งที่เหมาะสมกับตัวเลขของคุณเพื่อที่การจัดการจะไม่กลายเป็นปัญหาคอขวด

การพิจารณาดาต้าเซ็นเตอร์ไม่ได้ลดลงบ่อยครั้งหลาย ๆ เว็บไซต์หมายถึง load balancing และการแฮ็ค DNS บางตัวมันจะอยู่ในดาต้าเซ็นเตอร์เดียวกันหรือไม่ ถ้าเป็นเช่นนั้นถ้าศูนย์ข้อมูลหนึ่งศูนย์ล้มเหลวไม่ว่าด้วยเหตุผลใดก็ตามคุณจะพบปัญหาเพราะส่วนที่ดีของ DNS ของคุณและการปรับสมดุลการโหลดจะอยู่ในศูนย์ข้อมูลนี้

ดังนั้นคุณอาจต้องวางแผนว่าสถานการณ์สมองแยก สำหรับ almsot แต่ละการตั้งค่าที่เป็นไปได้วิธีการแก้ไขสถานการณ์น้ำลายสมองแตกต่างกัน นอกจากนี้แต่ละโซลูชันยังใช้เวลา X
มันอาจจะง่ายกว่าการวางแผนที่จะใช้ 3 ดาต้าเซ็นเตอร์ตั้งแต่เริ่มต้น ฉันไม่ใช่ผู้เชี่ยวชาญ MySQL แต่ฉันได้ยินมาว่าในการผลิตมันง่ายกว่าที่จะมี 3 Masters มากกว่า 2 ถ้าคุณเคยเจอปัญหา

สิ่งหนึ่งที่อาจช่วยคุณได้คือบริการสร้างความสมดุลให้กับผู้ให้บริการเครือข่ายบางรายเช่น Zeus ดูที่นี่อาจมีอีกหลายบริการที่เสนอนี้ ฉันแน่ใจว่ามันมีราคา แต่บางครั้งก็ช่วยให้คุณลดเรื่องอื่นลงได้

โชคดี!


ข้อมูลมีขนาดค่อนข้างเล็กทุกสิ่งที่พิจารณา สองสามร้อยกิกะไบต์เพื่อการอภิปราย ไซต์ที่สามน่าจะเป็น หากจำเป็นฉันยินดีที่จะประนีประนอมสถาปัตยกรรมเพื่อการแก้ปัญหาที่ดีกว่าในขณะนี้และกลับมาเยี่ยมชมอีกครั้งในภายหลัง "คอขวดการจัดการ" หรือข้อกังวลด้านการบริหารอื่น ๆ อยู่นอกขอบเขตของคำถาม ความซ้ำซ้อนจะมีอยู่ในสถานที่สำหรับเทคโนโลยีการผลิตทั้งหมด จุดเน้นที่นี่คือ MySQL
วอร์เนอร์

0

DRBD ไม่ใช่โซลูชันที่แนะนำสำหรับศูนย์ข้อมูลระยะไกลเนื่องจากต้องการแบนด์วิดท์ที่อาจส่งผลต่อความเร็วของฐานข้อมูลและการจำลองแบบของคุณ วิธีแก้ปัญหาที่แนะนำคือ Master - Master Replication ปัญหาเดียวของเรื่องนี้คือคุณต้องเพิ่มฟิลด์อัตโนมัติ

หากคุณต้องการโซลูชัน HA อย่างแท้จริงสำหรับ MySQL คุณจะต้องไปกับ MySQL Cluster เนื่องจาก DRBD ไม่สามารถให้ข้อมูลที่สมบูรณ์ในกรณีที่เกิดความล้มเหลว



0

การเอาชนะการขาดสายเคเบิลอนุกรมนั้นง่ายจริง ๆ คุณใช้สิ่งต่าง ๆ ในยุคมืดที่เรียกว่าโมเด็ม - คุณมีปลายสายแต่ละอันจากนั้นเรียกใช้ Heartbeat ผ่านลิงก์ PPP คุณสามารถใช้เฟรมรีเลย์ ทั้งสองวิธีจะแก้ไขความกังวลที่คุณมีกับเส้นทางที่ซ้ำซ้อนของเลเยอร์ 1/2

อย่างไรก็ตามมีการกล่าวว่า - DRBD ทำงานบนลิงก์ใด ๆ ที่มีมากกว่า 300µs (ทราบว่า 0.3ms) เวลาแฝงจะกลายเป็นเรื่องไร้สาระอย่างรวดเร็ว

คุณจะได้รับบริการที่ดีขึ้นโดยใช้การจำลองแบบ MySQL มาตรฐานและ LinuxHA บน PPP & eth เพื่อทำโอเวอร์โอเวอร์ที่ล้มเหลว

อย่างน้อยนั่นคือสิ่งที่ฉันได้ทำเพื่อลูกค้าในอดีต


ความคิดที่น่าสนใจ ฉันเคยใช้ dial-up เป็น failover บน PtP มาก่อน ในขณะที่ฉันไม่คิดว่ามันจะเป็นการขจัดปัญหาทฤษฎีบท CAP อย่างสมบูรณ์ แต่ฉันเชื่อว่านี่อาจเป็นส่วนเสริมที่ทำให้สมองแยกได้เกิดขึ้นน้อยลง ยากที่จะสร้างความมั่นใจในระดับเดียวกับที่สร้างขึ้นโดยการเชื่อมต่อทางกายภาพโดยตรงหลายฟุต
วอร์เนอร์
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.