SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • Products
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • การทดสอบอาหารสัตว์
  • ข่าวสารและกิจกรรม
  • ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์
  • เรื่องราวความสำเร็จ
  • ติดต่อเรา
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

โซลูชัน SAP High Availability สำหรับ Linux

ธันวาคม 3, 2018 by Jason Aw Leave a Comment

โซลูชันความพร้อมใช้งานสูงของ SAP

โซลูชัน SAP High Availability สำหรับ Linux

คุณกำลังมองหาโซลูชันที่มีประสิทธิภาพ แต่ใช้งานง่ายมีความพร้อมใช้งานสูง / Disaster Recovery สำหรับสภาพแวดล้อม SAP ของคุณหรือไม่ ถ้าเป็นเช่นนั้นคุณจะต้องดูที่ SteelEye Protection Suite (SPS) สำหรับ Linux จาก SIOS Technologies  SPS มีฟังก์ชันการทำงานของ High Availability และ Data Replication ที่สามารถทำงานร่วมกับเซิร์ฟเวอร์หรือการกำหนดค่าที่เก็บข้อมูล  การสนับสนุน SAP มีให้โดยไม่จำเป็นต้องมีการเขียนสคริปต์หรือปรับแต่งใด ๆ

SPS สำหรับ Linux เพิ่งได้รับการรับรองอย่างเป็นทางการจาก SAP กับ“ SAP NetWeaver High Availability Cluster 730 Certification” (NW-HA-CLU 730) รายการโซลูชัน HA ที่ผ่านการรับรองสำหรับ SAP สามารถพบได้ที่นี่: http://scn.sap.com / docs / DOC-31701 สำหรับข้อมูลเพิ่มเติมเกี่ยวกับโซลูชันความพร้อมใช้งานสูงของ SAP สำหรับ Linux โปรดส่งบันทึกย่อให้เราทำซ้ำได้รับอนุญาตจาก Linuxclustering

Filed Under: ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์ Tagged With: sap โซลูชั่นความพร้อมสูง

วิธีการสร้างคลัสเตอร์ MySQL แบบ 2 โหนดโดยไม่ใช้ Shared Storage – ตอนที่ 2

พฤศจิกายน 30, 2018 by Jason Aw Leave a Comment

สร้างคลัสเตอร์ MySQL แบบ 2 โหนดโดยไม่มีที่เก็บข้อมูลที่ใช้ร่วมกัน

ทีละขั้นตอน: วิธีการสร้างคลัสเตอร์ MySQL แบบ 2 โหนดโดยไม่มีที่เก็บข้อมูลที่ใช้ร่วมกันตอนที่ 2

โพสต์ก่อนหน้านี้นำข้อได้เปรียบของการใช้งานคลัสเตอร์ MySQL โดยใช้การกำหนดค่าการจัดเก็บข้อมูลที่ใช้ร่วมกันไม่มีอะไร นอกจากนี้เรายังเริ่มเดินผ่านกระบวนการตั้งค่าคลัสเตอร์โดยใช้การจำลองแบบข้อมูลและ SteelEye Protection Suite (SPS) สำหรับ Linux ในโพสต์นี้เราเสร็จสิ้นกระบวนการสร้าง 2 โหนด MySQL Cluster โดยไม่มีที่เก็บข้อมูลที่ใช้ร่วมกัน มาเริ่มกันเลย.

การสร้างเส้นทาง Comm

ตอนนี้ก็ถึงเวลาที่จะเข้าใช้ SteelEye LifeKeeper GUI LifeKeeper เป็นส่วนประกอบที่รวมอยู่ใน SPS for Linux LifeKeeper GUI เป็นแอ็พพลิเคชันที่ใช้ Java ซึ่งสามารถเรียกใช้เป็นแอ็พพลิเคชัน Linux พื้นเมืองหรือเป็นแอพเพล็ตภายในเว็บเบราเซอร์ที่เปิดใช้งาน Java (GUI ใช้ Java RMI กับ callbacks ดังนั้นชื่อโฮสต์ต้องสามารถแก้ไขได้หรือคุณอาจได้รับข้อผิดพลาด Java 115 หรือ 116) เมื่อต้องการเริ่มใช้งาน GUI ให้ป้อนคำสั่งนี้ในโหนดคลัสเตอร์ใดก็ได้: / opt / LifeKeeper / bin / lkGUIapp & หรือเพื่อเปิดแอพเพล็ต GUI จากเว็บเบราเซอร์ให้ไปที่ http: // <hostname>: 81

ขั้นตอนแรกคือตรวจสอบให้แน่ใจว่าคุณมีเส้นทางการสื่อสาร TCP (Comm) อย่างน้อยสองเส้นทางระหว่างเซิร์ฟเวอร์หลักแต่ละเครื่องกับเซิร์ฟเวอร์เป้าหมายแต่ละรายเพื่อลดความซ้ำซ้อนของ heartbeat วิธีนี้ความล้มเหลวของสายการสื่อสารหนึ่งจะไม่ทำให้เกิดสถานการณ์สมองแตก ตรวจสอบเส้นทางบนเซิร์ฟเวอร์หลัก ภาพหน้าจอต่อไปนี้นำคุณสู่ขั้นตอนการเข้าสู่ GUI การเชื่อมต่อกับโหนดคลัสเตอร์และการสร้างเส้นทาง Comm

ขั้นตอนที่ 1: เชื่อมต่อกับเซิร์ฟ20181128 cnaonline SUSS บรรจุวิทยากรเพื่อให้คำถามและคำตอบเกี่ยวกับการรั่วไหลของหลักสูตร.pdfเวอร์หลักขั้นตอนที่ 2: เชื่อมต่อกับเภาพกวดวิชาซิร์ฟเวอร์รองขั้นตอนที่ 3: สรภาพกวดวิชา้างเส้นทางการสื่อสารขั้นตอนที่ 4: เลือกเซิรภาพกวดวิชา์ภาพกวดวิชาฟเวอร์ในพื้นที่และระยะไกลขัภาพกวดวิชา้นตอนที่ 5: เลือกประเภทอุปกรณ์ถัดไปคุณจะเห็นกล่องโต้ตอบ สำหรับแต่ละช่องให้ระบุข้อมูลที่ต้องการและคลิกถัดไปเพื่อดำเนินการต่อ (สำหรับแต่ละฟิลด์ในกล่องโต้ตอบคุณสามารถคลิกวิธีใช้เพื่อดูข้อมูลเพิ่มเติม) ขั้นตอนที่ 6: เลือกที่อยู่ IP สำหรับเซิร์ฟเวอร์ภายในเครื่องเพื่อใช้เส้นทางการสื่อสภาพกวดวิชาารขั้นตอนที่ 7: เลือกที่อยู่ IP สำหรับเซิร์ฟเวอร์ระยะไกลเพื่อใช้เส้นทาภาพกวดวิชาง Comm ขั้นตอนที่ 8: ป้อน จัดลำดับความสำคัญพา ธ บนเซิภาพกวดวิชาร์ฟเวอร์ภายในหลังจากป้อนข้อมูลในฟิลด์ที่จำเป็นทั้งหมดแล้วคลิกสร้าง คุณจะเห็นข้อความที่ระบุว่าได้สร้างเส้นทาง Comm Comm ของเครือข่ายแล้ว ขั้นตอนที่ 9: เสร็จสิ้นการสร้างเส้นทาง ภาพกวดวิชาComm คลิกถัดไป ถ้าคุณเลือกที่อยู่ IP ภายในเครื่องหลายเครื่องหรือเซิร์ฟเวอร์ระยะไกลและตั้งค่าประเภทอุปกรณ์เป็น TCP ขั้นตอนนี้จะส่งกลับไปยังวิซาร์ดการตั้งค่าเพื่อสร้างเส้นทาง Comm ถัดไป เมื่อดำเนินการเสร็จสิ้นให้คลิกเสร็จสิ้นในกล่องโต้ตอบสุดท้าย ทำซ้ำขั้นตอนนี้จนกว่าคุณจะกำหนดเส้นทาง Comm ทั้งหมดที่คุณวางแผนจะใช้ ตรวจสอบว่าเส้นทางการติดต่อสื่อสารถูกกำหนดค่าอย่างถูกต้องโดยการดูกล่องโต้ตอบคุณสมบัติของเซิร์ฟเวอร์ จาก GUI ให้เลือก Edit> Server> Properties จากนั้นเลือกแท็บ CommPaths สถานะที่แสดงควรเป็น ALIVE นอกจากนี้คุณยังสามารถตรวจสอบไอคอนเซิร์ฟเวอร์ที่ด้านขวามือของ GUI หากมีการสร้างเส้นทาง Comm เพียงอย่างเดียวไอคอนเซิร์ฟเวอร์จะซ้อนทับด้วยไอคอนคำเตือนสีเหลือง เครื่องหมายถูกสีเขียวแสดงว่าเส้นทาง Comm มีอย่างน้อยสองเส้นทางและ ALIVE ขั้นตอนที่ 10: ตรวจสอบสถานะเส้นทางของ Comm ภาพกวดวิชา

การสร้างและขยายทรัพยากร IP

ใน LifeKeeper GUI ให้สร้างทรัพยากร IP และขยายไปยังเซิร์ฟเวอร์สำรองโดยทำตามขั้นตอนต่อไปนี้ IP เสมือนนี้สามารถย้ายระหว่างโหนดคลัสเตอร์พร้อมกับแอ็พพลิเคชันที่ขึ้นอยู่กับ เมื่อใช้ IP เสมือนเป็นส่วนหนึ่งของการกำหนดค่าคลัสเตอร์ของคุณคุณจะให้การเปลี่ยนเส้นทางไคลเอ็นต์ได้อย่างราบรื่นเมื่อมีการเปลี่ยนหรือล้มเหลวระหว่างทรัพยากรระหว่างโหนดคลัสเตอร์เนื่องจากพวกเขายังคงเข้าถึงฐานข้อมูลผ่านทาง FQDN / IP เดียวกัน ขั้นตอนที่ 11: สร้างลำดับชั้นขภาพกวดวิชาองทรัพยากรขั้นตอนที่ ภาพกวดวิชา12: เลือก IP ARK ป้อนข้อมูลที่เหมาะสมสำหรับการกำหนดค่าของคุณโดยใช้ค่าที่แนะนำต่อไปนี้ (คลิกปุ่มวิธีใช้สำหรับข้อมูลเพิ่มเติม) คลิกถัดไปเพื่อดำเนินการต่อหลังจากป้อนข้อมูลที่ต้องการ

สนาม

เคล็ดลับ

ประเภททรัพยากร เลือกที่อยู่ IP เป็นประเภทรีซอร์สและคลิกถัดไป
ประเภท Switchback เลือกอัจฉริยะและคลิกถัดไป
เซิร์ฟเวอร์ เลือกเซิร์ฟเวอร์ที่จะสร้างทรัพยากร IP เลือกเซิร์ฟเวอร์หลักของคุณและคลิกถัดไป
ทรัพยากร IP ป้อนข้อมูล IP เสมือนและคลิกถัดไป (นี่คือที่อยู่ IP ที่ไม่ได้ใช้งานที่ใดก็ได้ในเครือข่ายของคุณ ลูกค้าทั้งหมดจะใช้ที่อยู่นี้เพื่อเชื่อมต่อกับแหล่งข้อมูลที่มีการป้องกัน)
เน็ตมาสก์ ป้อนซับเน็ตมาสก์ IP ที่ทรัพยากร TCP / IP ของคุณจะใช้บนเซิร์ฟเวอร์เป้าหมาย netmask มาตรฐานใด ๆ สำหรับระดับของที่อยู่ของทรัพยากร TCP / IP ที่ระบุถูกต้อง ซับเน็ตมาสก์รวมกับที่อยู่ IP กำหนดซับเน็ตที่ทรัพยากร TCP / IP จะใช้และควรสอดคล้องกับการกำหนดค่าเครือข่ายการกำหนดค่าตัวอย่างนี้ 255.255.255.0 ใช้กับซับเน็ตมาสก์ในเครือข่ายทั้งสอง
การเชื่อมต่อเครือข่าย ใช้การ์ดอีเทอร์เน็ตแบบกายภาพกับส่วนติดต่อที่อยู่ IP เลือกการเชื่อมต่อเครือข่ายที่จะอนุญาตให้ที่อยู่ IP เสมือนของคุณสามารถกำหนดเส้นทางได้ เลือก NIC ที่ถูกต้องและคลิก Next
แท็กทรัพยากร IP ยอมรับค่าดีฟอลต์และคลิก Next ค่านี้จะส่งผลต่อวิธีการแสดง IP ใน GUI เท่านั้น ทรัพยากร IP จะถูกสร้างขึ้นในเซิร์ฟเวอร์หลัก

LifeKeeper สร้างและตรวจสอบความถูกต้องของทรัพยากรของคุณ หลังจากได้รับข้อความว่ามีการสร้างรีซอร์สเรียบร้อยแล้วคลิกถัดไป ขั้นตอนที่ 13: ตรวจสอบการบอกกล่าวเกี่ยวกับการสร้างทรัพยภาพกวดวิชาากรที่ประสบความสำเร็จในตอนนี้คุณสามารถทำกระบวนการขยายทรัพยากร IP ไปยังเซิร์ฟเวอร์รองได้ ขั้นตอนที่ 14: ขยายทรัพยากร IP ไปยังเซิร์ฟภาพกวดวิชาเวอร์รองกระบวนการขยายทรัพยากร IP เริ่มต้นโดยอัตโนมัติหลังจากที่คุณสร้างทรัพยากรที่อยู่ IP เสร็จสิ้นแล้วคลิกถัดไป นอกจากนี้คุณสามารถเริ่มต้นกระบวนการนี้จากทรัพยากรที่อยู่ IP ที่มีอยู่ด้วยการคลิกขวาที่ทรัพยากรที่ใช้งานอยู่และเลือก Extend Resource Hierarchy ใช้ข้อมูลในตารางต่อไปนี้เพื่อทำตามขั้นตอน

สนาม

รายการแนะนำหรือหมายเหตุ

ประเภท Switchback ปล่อยให้เป็นอัจฉริยะและคลิกถัดไป
ลำดับความสำคัญเทมเพลต ปล่อยให้เป็นค่าเริ่มต้น (1)
ลำดับความสำคัญเป้าหมาย ปล่อยให้เป็นค่าเริ่มต้น (10)
เชื่อมต่อเครือข่าย นี่คือการ์ดอีเทอร์เน็ตที่มีส่วนติดต่อกับที่อยู่ IP เลือกการเชื่อมต่อเครือข่ายที่จะอนุญาตให้ที่อยู่ IP เสมือนของคุณสามารถกำหนดเส้นทางได้ ควรเลือก NIC ทางกายภาพที่ถูกต้องโดยค่าเริ่มต้น ยืนยันแล้วคลิกถัดไป
แท็กทรัพยากร IP ปล่อยให้เป็นค่าเริ่มต้น
โหมดคืนค่าเป้าหมาย เลือกเปิดใช้งานและคลิกถัดไป
เป้าหมายการกู้คืนภายในประเทศ เลือกใช่เพื่อเปิดใช้งานการกู้คืนภายในเครื่องสำหรับรีซอร์ส SQL บนเซิร์ฟเวอร์เป้าหมาย
ลำดับความสำคัญการสำรองข้อมูล ยอมรับค่าเริ่มต้น

หลังจากได้รับข้อความว่าการดำเนินการส่วนขยายลำดับชั้นเสร็จสิ้นแล้วให้คลิกเสร็จสิ้นแล้วคลิกเสร็จสิ้น ทรัพยากร IP ของคุณ (ตัวอย่าง: 192.168.197.151) ได้รับการป้องกันอย่างสมบูรณ์และสามารถลอยระหว่างโหนดคลัสเตอร์ได้ตามต้องการ ใน LifeKeeper GUI คุณจะเห็นว่าทรัพยากร IP แสดงเป็น Active ในโหนดคลัสเตอร์หลักและ Standby ในโหนดลำดับที่สอง ขั้นตอนที่ 15: ตรวจสอบสถานะทรัพยากร IP บนโหนดหลักและรอง ภาพกวดวิชา

การสร้างกระจกเงาและเริ่มต้นการจำลองข้อมูล

ครึ่งทางในการสร้างคลัสเตอร์ MySQL แบบ 2 โหนดโดยไม่ใช้ที่เก็บข้อมูลร่วมกัน! คุณพร้อมที่จะตั้งค่าและกำหนดค่ารีซอร์สการจำลองข้อมูลซึ่งคุณจะใช้เพื่อซิงโครไนซ์ข้อมูล MySQL ระหว่างโหนดคลัสเตอร์ สำหรับตัวอย่างนี้ข้อมูลที่จะทำซ้ำอยู่ในพาร์ติชัน / var / lib / mysql บนโหนดคลัสเตอร์หลัก ปริมาณไดรฟ์ข้อมูลต้องถูกติดตั้งบนเซิร์ฟเวอร์หลักไดรฟ์ข้อมูลเป้าหมายต้องไม่ถูกติดตั้งบนเซิร์ฟเวอร์รองและขนาดไดรฟ์ข้อมูลเป้าหมายต้องเท่ากับหรือใหญ่กว่าขนาดไดรฟ์ข้อมูลต้นฉบับ ภาพหน้าจอต่อไปนี้แสดงชุดของขั้นตอนถัดไป ขั้นตอนที่ 16: สร้างลำดับชั้นของทรัภาพกวดวิชาพยากรขั้นตอนที่ 17: เลือกการจำลองแบบข้อภาพกวดวิชามูล ARK ใช้ค่าเหล่านี้ในตัวช่วยสร้างการจำลองข้อมูล

สนาม

รายการแนะนำหรือหมายเหตุ

ประเภท Switchback เลือกที่ชาญฉลาด
เซิร์ฟเวอร์ เลือก LinuxPrimary (โหนดคลัสเตอร์หลักหรือแหล่งมิเรอร์)
ลำดับชั้น เลือกทำซ้ำระบบแฟ้มที่มีอยู่
Mount Point ที่มีอยู่ เลือกพาร์ทิชันที่ติดตั้งเพื่อทำซ้ำ; ในตัวอย่างนี้ / var / lib / mysql
แท็กรีซอร์สข้อมูลรีซอร์ส ปล่อยให้เป็นค่าเริ่มต้น
แท็กทรัพยากรระบบไฟล์ ปล่อยให้เป็นค่าเริ่มต้น
ไฟล์ Bitmap ปล่อยให้เป็นค่าเริ่มต้น
เปิดใช้งานการจำลองแบบอะซิงโครนัส ปล่อยให้เป็นค่าเริ่มต้น (ใช่)

คลิกถัดไปเพื่อเริ่มต้นสร้างลำดับชั้นรีซอร์สข้อมูล GUI จะแสดงข้อความต่อไปนี้ ขั้นตอนที่ 18: เริ่มต้นสร้างทรัพยากรการจำลองแภาพกวดวิชาบบข้อมูลคลิกถัดไปเพื่อเริ่มกระบวนการขยายทรัพยากรการจำลองแบบข้อมูล ยอมรับการตั้งค่าเริ่มต้นทั้งหมด เมื่อถามดิสก์เป้าหมายเลือกพาร์ติชันฟรีในเซิร์ฟเวอร์เป้าหมายที่คุณสร้างขึ้นก่อนหน้านี้ในกระบวนการนี้ ตรวจสอบให้แน่ใจว่าได้เลือกพาร์ติชันที่ใหญ่หรือใหญ่กว่าไดรฟ์ข้อมูลต้นฉบับและไม่ได้ติดตั้งอยู่ในระบบเป้าหมาย ขั้นตอนที่ 19: เริ่มต้นส่วนขยายของทรัพยากรกาภาพกวดวิชารจำลองแบบข้อมูลในที่สุดคุณจะได้รับแจ้งให้เลือกเครือข่ายที่คุณต้องการให้มีการจำลองแบบ โดยทั่วไปการแยกผู้ใช้และแอ็พพลิเคชันจากการเข้าชมการจำลองแบบของคุณเป็นแนวทางที่ดีที่สุด การกำหนดค่าตัวอย่างนี้มีอินเทอร์เฟซเครือข่ายสองแบบคือ "public NIC" ในเครือข่ายย่อย 192.168.197.X และ "private / backend NIC" ในเครือข่ายย่อย 192.168.198.X เราจะกำหนดค่าการจำลองแบบเพื่อไปยังเครือข่าย back-end 192.168.198.X เพื่อให้ผู้ใช้และแอ็พพลิเคชันการจราจรไม่สามารถแข่งขันกับการจำลองแบบได้ ขั้นตอนที่ 20: เลือกเครือข่ายสำหรับการรับส่งข้อมูลการจภาพกวดวิชาำลองแบบคลิกถัดไปเพื่อดำเนินการต่อผ่านตัวช่วยสร้าง ขั้นตอนที่ 21: ทบทวนลำดับชั้นทรัพยากรการจำลองข้อมูลข้อมูล ภาพกวดวิชา

การสร้างลำดับชั้นทรัพยากรของ MySQL

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

สนาม

รายการแนะนำหรือหมายเหตุ

ประเภท Switchback เลือกที่ชาญฉลาด
เซิร์ฟเวอร์ เลือก LinuxPrimary (โหนดคลัสเตอร์หลัก)
ตำแหน่งของ my.cnf Enter / var / lib / MySQL (ก่อนหน้านี้ในกระบวนการกำหนดค่า MySQL คุณได้สร้างไฟล์ my.cnf ไว้ในไดเรกทอรีนี้)
ตำแหน่งของไฟล์ปฏิบัติการ MySQL ปล่อยให้เป็นค่าเริ่มต้น (/ usr / bin) เนื่องจากคุณใช้ MySQL มาตรฐานในการติดตั้ง / กำหนดค่าในตัวอย่างนี้
แท็กฐานข้อมูล ปล่อยให้เป็นค่าเริ่มต้น

  คลิกสร้างเพื่อกำหนดลำดับชั้นทรัพยากรของ MySQL บนเซิร์ฟเวอร์หลัก คลิกถัดไปเพื่อขยายทรัพยากรระบบไฟล์ไปยังเซิร์ฟเวอร์สำรอง ในตัวช่วยสร้างส่วนขยายให้เลือกยอมรับค่าดีฟอลต์ คลิก Finish เพื่อออกจาก Extend wizard ลำดับชั้นทรัพยากรของคุณควรมีลักษณะดังนี้: ขั้นตอนที่ 22: ทบทวนลำดับชั้นทรัพยากรของ MySQL ภาพกวดวิชา

การสร้างการพึ่งพาที่อยู่ IP ของ MySQL

ถัดไปคุณจะต้องกำหนดค่า MySQL ให้ขึ้นอยู่กับ IP เสมือน (192.168.197.151) เพื่อให้ที่อยู่ IP ดังต่อไปนี้เป็นฐานข้อมูล MySQL ขณะที่ย้าย จากแถบเครื่องมือ GUI คลิกขวาที่ทรัพยากร mysql เลือกสร้างการพึ่งพาจากเมนูบริบท ในเมนูแบบเลื่อนลงแท็ก Resource Resource ของทรัพยากรให้เลือก ip-192.168.197.151 คลิกถัดไปคลิกสร้างการอ้างอิงจากนั้นคลิกเสร็จสิ้น ลำดับชั้นทรัพยากรของคุณควรมีลักษณะดังนี้: ขั้นตอนที่ 23: ตรวจสอบลำดับชั้นทรัพยากร IP ของ MภาพกวดวิชาySQL ณ จุดนี้ในการประเมินผลคุณได้รับการปกป้องอย่างเต็มที่จาก MySQL และทรัพยากรที่ต้องพึ่งพา (ที่อยู่ IP และที่เก็บแบบจำลอง) ทดสอบสภาพแวดล้อมของคุณและพร้อมแล้วที่จะไป คุณสามารถค้นหาข้อมูลเพิ่มเติมและขั้นตอนโดยละเอียดสำหรับทุกขั้นตอนของกระบวนการประเมินใน SIOS SteelEye Protection Suite สำหรับ Linux MySQL พร้อมคู่มือการประเมินผลการจำลองแบบข้อมูล หากต้องการดาวน์โหลดสำเนาการประเมินผลของ SPS สำหรับ Linux ให้ไปที่เว็บไซต์ SIOS หรือติดต่อ SIOS ที่ info@us.sios.com สนใจที่จะเรียนรู้วิธีสร้างคลัสเตอร์ MySQL แบบ 2 โหนดโดยไม่มีที่เก็บข้อมูลร่วมกันนี่คือเรื่องราวความสำเร็จในอดีตของเรากับลูกค้าที่พึงพอใจ ทำซ้ำโดยได้รับอนุญาตจาก Linuxclustering

Filed Under: ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์ Tagged With: MySQL, สร้างโหนดคลัสเตอร์ 2 โหนดโดยไม่มีที่เก็บข้อมูลที่ใช้ร่วมกัน

วิธีการสร้างคลัสเตอร์ MySQL แบบ 2 โหนดโดยไม่มีที่เก็บข้อมูลที่ใช้ร่วมกัน – ตอนที่ 1

พฤศจิกายน 29, 2018 by Jason Aw Leave a Comment

สร้างคลัสเตอร์ MySQL แบบ 2 โหนดโดยไม่มีที่เก็บข้อมูลที่ใช้ร่วมกัน

ทีละขั้นตอน: วิธีการสร้างคลัสเตอร์ MySQL 2 โหนดโดยไม่มีที่เก็บข้อมูลที่ใช้ร่วมกันตอนที่ 1

ประโยชน์หลักของการรันกลุ่ม MySQL คือความพร้อมใช้งานที่สูง (HA) ที่เห็นได้ชัด เพื่อให้ได้ประโยชน์สูงสุดจากโซลูชันประเภทนี้คุณจะต้องการกำจัดจุดล้มเหลวเพียงจุดเดียวที่อาจเป็นไปได้ ภูมิปัญญาดั้งเดิมบอกว่าคุณไม่สามารถสร้างกลุ่มโดยไม่มีที่เก็บข้อมูลที่แชร์กันซึ่งแสดงให้เห็นถึงจุดเด่นด้านสถาปัตยกรรมแบบคลัสเตอร์ของคุณ อย่างไรก็ตามมีโซลูชันอยู่ SteelEye Protection Suite (SPS) สำหรับ Linux ช่วยให้คุณสามารถกำจัดการจัดเก็บข้อมูลเป็นจุดเดียวของความล้มเหลวโดยการให้ข้อมูลการจำลองแบบเรียลไทม์ระหว่างโหนดคลัสเตอร์ ลองดูที่สถานการณ์ทั่วไป: คุณฟอร์มคลัสเตอร์ที่ยกระดับพื้นที่เก็บข้อมูลแบบจำลองเพื่อปกป้องฐานข้อมูล MySQL

ในการสร้างสร้างคลัสเตอร์แบบ 2 โหนดโดยไม่ใช้ Shared Storage เราจะสมมติว่าคุณกำลังทำงานกับสำเนาประเมินผลของ SPS ในสภาพแวดล้อมของแล็บ เรายังสันนิษฐานว่าคุณได้ยืนยันว่าเซิร์ฟเวอร์หลักและเซิร์ฟเวอร์สำรองและเครือข่ายทั้งหมดมีคุณสมบัติตรงตามข้อกำหนดในการใช้งานการตั้งค่าประเภทนี้ (คุณสามารถดูรายละเอียดของข้อกำหนดเหล่านี้ได้ใน SIOS SteelEye Protection Suite สำหรับ Linux MySQL พร้อมคู่มือการประเมินผลการจำลองข้อมูล)

ขั้นตอนแรกในการสร้าง 2-Node MySQL Cluster Without Shared Storage

ก่อนที่คุณจะเริ่มตั้งค่าคลัสเตอร์คุณต้องกำหนดค่าพื้นที่เก็บข้อมูล ข้อมูลที่คุณต้องการทำซ้ำต้องอาศัยระบบไฟล์หรือไดรฟ์ข้อมูลแบบตรรกะ โปรดจำไว้ว่าขนาดของดิสก์เป้าหมายไม่ว่าคุณจะใช้พาร์ติชันหรือไดรฟ์ลอจิกต้องมีค่าเท่ากับหรือใหญ่กว่าแหล่งข้อมูล ในตัวอย่างนี้เราถือว่าคุณกำลังใช้พาร์ทิชันดิสก์ (แต่ LVM ยังได้รับการสนับสนุนอย่างเต็มที่) ขั้นแรกให้แบ่งพื้นที่เก็บข้อมูลในเครื่องเพื่อใช้กับ SteelEye DataKeeper บนเซิร์ฟเวอร์หลักระบุพาร์ติชันดิสก์ฟรีที่ไม่ได้ใช้เพื่อใช้เป็นที่เก็บ MySQL หรือสร้างพาร์ติชันใหม่ ใช้อรรถประโยชน์ fdisk เพื่อแบ่งพาร์ติชันดิสก์จากนั้นจัดรูปแบบพาร์ติชันและติดตั้งชั่วคราวที่ / mnt ย้ายข้อมูลที่มีอยู่จาก / var / lib / mysql / ลงในพาร์ติชันดิสก์ใหม่ (สมมติว่ามีการกำหนดค่า MySQL เริ่มต้น) เลิกเมานท์แล้วย้ายพาร์ติชันใหม่ที่ / var / lib / mysql คุณไม่จำเป็นต้องเพิ่มพาร์ติชันนี้ใน / etc / fstab เนื่องจากจะติดตั้งโดยอัตโนมัติโดย SPS บนเซิร์ฟเวอร์สำรองกำหนดค่าดิสก์ของคุณเหมือนกับที่คุณทำบนเซิร์ฟเวอร์หลัก

กำลังติดตั้ง MSQL

ถัดไปคุณจะจัดการกับ MySQL บนเซิร์ฟเวอร์หลักติดตั้งแพคเกจ RPM mysql และ mysql-server (ถ้าไม่มีอยู่ในระบบ) และใช้การพึ่งพาที่ต้องการ ตรวจสอบว่าพาร์ติชันดิสก์ภายในเครื่องของคุณยังคงติดตั้งอยู่ที่ / var / lib / mysql ถ้าจำเป็นให้เริ่มต้นตัวอย่างฐานข้อมูล MySQL ตรวจสอบให้แน่ใจว่าไฟล์ทั้งหมดในไดเร็กทอรีข้อมูล MySQL (/ var / lib / mysql) มีสิทธิ์และการเป็นเจ้าของที่ถูกต้องจากนั้นเริ่ม MySQL daemon จากบรรทัดคำสั่งด้วยตนเอง (หมายเหตุ: อย่าเริ่ม MySQL ผ่านทางคำสั่งบริการหรือ /etc/init.d/ script) เชื่อมต่อกับ mysql client เพื่อตรวจสอบว่า MySQL กำลังทำงานอยู่ อัพเดตและยืนยันรหัสผ่าน root สำหรับการกำหนดค่า MySQL ของคุณ จากนั้นสร้างไฟล์การกำหนดค่า MySQL เช่นไฟล์ตัวอย่างที่แสดงที่นี่: ## cat /var/lib/mysql/my.cnf [mysqld] datadir = / var / lib / mysql socket = / var / lib / mysql /mysql.sock pid-file = / var / lib / mysql.pid user = root port = 3306 # เริ่มต้นใช้รูปแบบรหัสผ่านเดิมสำหรับเข้ากันได้กับ mysql 3.x # clients (ใช้แพ็คเกจความเข้ากันได้กับ mysqlclient10) old_passwords = 1 # การปิดใช้งานการเชื่อมโยงสัญลักษณ์แนะนำเพื่อป้องกันความเสี่ยงด้านความปลอดภัยต่างๆ # การทำเช่นนี้ uncomment บรรทัดนี้: # symbolic-links = 0 [mysqld_safe] log-error = / var / log / mysqld.log pid-file = / var / run / mysqld / mysqld.pid [client] user = root password = SteelEye —- ในตัวอย่างนี้เราวางไฟล์นี้ลงในไดเรกทอรีเดียวกันกับที่เราจะทำซ้ำในภายหลัง (/var/lib/mysql/my.cnf) ลบไฟล์การกำหนดค่า MySQL ต้นฉบับ (ใน / etc) ในเซิร์ฟเวอร์รองให้ติดตั้งแพคเกจ RPM mysql และ mysql-server หากจำเป็นใช้ dependencies ใด ๆ และตรวจสอบให้แน่ใจว่าไฟล์ทั้งหมดในไดเร็กทอรีข้อมูล MySQL (/ var / lib / mysql) มีสิทธิ์และการเป็นเจ้าของที่ถูกต้อง

การติดตั้ง SPS สำหรับ Linux

จากนั้นติดตั้ง SPS สำหรับ Linux เพื่อความสะดวกในการติดตั้ง SIOS มีสคริปต์การติดตั้งแบบรวม (เรียกว่า "setup") สำหรับ SPS for Linux คำแนะนำสำหรับการขอรับซอฟต์แวร์นี้อยู่ในอีเมลที่มาพร้อมกับคีย์ใบอนุญาตการประเมินผล SPS for Linux ดาวน์โหลดซอฟต์แวร์และคีย์ใบอนุญาตการประเมินผลบนทั้งเซิร์ฟเวอร์หลักและเซิร์ฟเวอร์สำรอง ในแต่ละเซิร์ฟเวอร์ให้เรียกใช้สคริปต์การติดตั้งซึ่งจะติดตั้ง RPM ที่ต้องการเบื้องต้นเป็นกลุ่มซอฟต์แวร์หลักในการจัดกลุ่มและ ARK ที่จำเป็นใด ๆ ที่จำเป็น ในกรณีนี้คุณจะต้องติดตั้ง MySQL ARK (steeleye-lkSQL) และ DataKeeper (เช่น Data Replication) ARK (steeleye-lkDR) ใช้คีย์ใบอนุญาตผ่านคำสั่ง / opt / LifeKeeper / bin / lkkeyins และเริ่ม SPS สำหรับ Linux ผ่านทางสคริปต์เริ่มต้น / opt / LifeKeeper / lkstart ณ จุดนี้คุณมี SPS ติดตั้งได้รับอนุญาตและใช้งานได้ทั้งโหนดของคุณและดิสก์ของคุณและฐานข้อมูล MySQL ที่คุณต้องการปกป้องมีการกำหนดค่า ในโพสต์ถัดไปเราจะดูขั้นตอนที่เหลือในกระบวนการทำคลัสเตอร์แบบไม่มีส่วนแบ่ง: สร้างสิ่งต่อไปนี้

  • เส้นทางการสื่อสาร (Comm) ได้แก่ heartbeats ระหว่างเซิร์ฟเวอร์หลักและเซิร์ฟเวอร์เป้าหมาย
  • ทรัพยากร IP
  • กระจกและการจำลองข้อมูลการเปิดตัว
  • ทรัพยากรฐานข้อมูล MySQL
  • การพึ่งพาที่อยู่ IP ของ MySQL

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

Filed Under: ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์ Tagged With: MySQL, สร้างโหนดคลัสเตอร์ 2 โหนดโดยไม่มีที่เก็บข้อมูลที่ใช้ร่วมกัน

Failover Clustering ด้วย VMware High Availability การจับคู่ที่สมบูรณ์แบบ?

พฤศจิกายน 28, 2018 by Jason Aw Leave a Comment

การทำคลัสเตอร์ล้มเหลวด้วย VMware ความพร้อมใช้งานสูง

Failover Clustering ด้วย VMware High Availability: Overkill หรือ Perfect Match?

การใช้ห้องว่างสูง (HA) ที่ชั้น VMware เป็นโซลูชันที่มีประโยชน์ ช่วยป้องกันความผิดพลาดบางประเภท อย่างไรก็ตาม VMware HA เพียงอย่างเดียวไม่ครอบคลุมฐานทั้งหมด ลองสำรวจความเป็นไปได้ของ Failover Clustering ด้วย VMware High Availability

ตามรายงานของ Gartner Research การขาดงานโดยไม่ตั้งใจส่วนใหญ่เกิดจากความล้มเหลวของโปรแกรม (40 เปอร์เซ็นต์ของการหยุดให้บริการ) หรือความผิดพลาดของผู้ดูแลระบบ (40 เปอร์เซ็นต์) ปัญหาเกี่ยวกับฮาร์ดแวร์เครือข่ายปัญหาด้านพลังงานหรือปัญหาด้านสิ่งแวดล้อมทำให้เกิดส่วนที่เหลือ (รวม 20 เปอร์เซ็นต์) VMware HA มุ่งเน้นการป้องกันความล้มเหลวของฮาร์ดแวร์ แต่โซลูชันการจัดกลุ่มแอพพลิเคชันที่ดีจะช่วยลดปัญหาในพื้นที่อื่น ๆ

การมีกลยุทธ์ที่ดีเป็นสิ่งสำคัญสำหรับการทำคลัสเตอร์ล้มเหลวด้วย VMware High Availability

ต่อไปนี้เป็นสิ่งที่ควรพิจารณาเมื่อออกแบบกลยุทธ์ HA ที่เหมาะสำหรับสภาพแวดล้อม VMware ของคุณ Failover Clustering ด้วย VMware High Availability การจับคู่ที่สมบูรณ์แบบ?

ตัดทอนให้สั้นลงด้วยการตรวจสอบระดับแอ็พพลิเคชันและการจัดกลุ่ม

สิ่งที่เกี่ยวกับความเร็วการกู้คืน? ในโลกที่สมบูรณ์แบบจะไม่มีความล้มเหลวการหยุดทำงานหรือการหยุดทำงาน แต่ถ้ามีการหยุดทำงานโดยไม่ได้ตั้งใจเกิดขึ้นสิ่งที่ดีที่สุดถัดไปคือการลุกขึ้นและวิ่งเร็วอีกครั้ง สมการนี้แสดงถึงความพร้อมใช้งานทั้งหมดของสภาพแวดล้อมของคุณ: ตามที่คุณเห็นเวลาในการตรวจจับเป็นส่วนสำคัญของสมการ นี่เป็นอีกหนึ่งสถานที่ที่ VMware HA คนเดียวไม่ค่อยตัดมัน VMware HA จะถือว่าเครื่องเสมือน (VM) แต่ละเครื่องเป็น "กล่องดำ" และไม่มีการเปิดเผยที่แท้จริงต่อสุขภาพหรือสถานะของแอ็พพลิเคชันที่กำลังทำงานอยู่ภายใน VM และ OS ที่ทำงานอยู่ภายในอาจดีกว่า แต่แอ็พพลิเคชันอาจหยุดทำงานแขวนหรือกำหนดค่าผิดพลาดส่งผลให้ผู้ใช้หยุดชะงักลง แม้ว่าเซิร์ฟเวอร์โฮสต์ปัญหาจะเป็นปัญหาคุณต้องรอ VMware HA เพื่อรีสตาร์ทเครื่อง VMs ที่ได้รับผลกระทบบนโฮสต์อื่นในคลัสเตอร์ VMware นั่นหมายความว่าแอพพลิเคชันที่รันบน VM เหล่านั้นจะหยุดลงจนกว่าจะมีการตรวจพบว่ามีการหยุดทำงาน 2) ระบบปฏิบัติการจะบูตระบบใหม่ทั้งหมด 3) แอพพลิเคชันเริ่มระบบใหม่และ 4) ผู้ใช้เชื่อมต่อกับแอพพลิเคชันใหม่ การจัดกลุ่มในเลเยอร์แอพพลิเคชันระหว่าง VMs หลายเครื่องคุณไม่เพียง แต่ได้รับการป้องกันจากการหยุดใช้งานระดับแอ็พพลิเคชันเท่านั้น แต่คุณยังลดระยะเวลาการกู้คืน แอ็พพลิเคชันสามารถเริ่มต้นใหม่บน VM สแตนด์บายซึ่งบูตขึ้นมาแล้วและรอที่จะรับช่วง เพื่อเพิ่มความพร้อมใช้งาน VM ที่เกี่ยวข้องควรอยู่บนเซิร์ฟเวอร์ทางกายภาพที่แตกต่างกัน หรือดียิ่งขึ้นแยกกลุ่ม VMware HA หรือแม้แต่ดาต้าเซ็นเตอร์แบบแยกต่างหาก!

กำจัดพื้นที่เก็บข้อมูลเป็นจุดบกพร่องเดียวที่อาจเกิดขึ้น (SPOF)

โซลูชันการจัดกลุ่มแบบดั้งเดิมรวมถึง VMware HA ต้องการพื้นที่เก็บข้อมูลที่ใช้ร่วมกันและมักจะปกป้องแอพพลิเคชันหรือบริการภายในศูนย์ข้อมูลเพียงแห่งเดียว ในทางเทคนิคอุปกรณ์จัดเก็บข้อมูลที่ใช้ร่วมกันหมายถึง SPOF ในสถาปัตยกรรมของคุณ ถ้าคุณสูญเสียการเข้าถึงที่เก็บข้อมูลแบ็กเอนด์คลัสเตอร์และแอพพลิเคชันจะไม่ทำงาน เป้าหมายของโซลูชัน HA คือการเพิ่มความพร้อมโดยรวมโดยการขจัด SPOF ที่เป็นไปได้ให้ได้มากที่สุด ดังนั้นคุณสามารถเพิ่มกลุ่ม VMware HA แบบเดิมเพื่อให้มีการใช้งานได้มากขึ้นหรือไม่? เพื่อป้องกันสแต็คทั้งหมดของคุณจากฮาร์ดแวร์ไปยังแอพพลิเคชันให้เริ่มต้นด้วย VMware HA ถัดไปคุณต้องมีวิธีการตรวจสอบและป้องกันแอปพลิเคชัน การจัดกลุ่มในระดับแอ็พพลิเคชัน (เช่นภายใน VM) เป็นทางเลือกที่เป็นธรรมชาติ อย่าลืมเลือกโซลูชันการจัดกลุ่มที่สนับสนุนการจำลองแบบข้อมูลตามโฮสต์ (เช่นการกำหนดค่าแบบใช้ร่วมกัน) เพื่อไม่ให้คุณต้องเสียค่าใช้จ่ายและความยุ่งยากในการตั้งค่าการจำลองแบบตาม SAN โซลูชันการจำลองแบบ SAN ยังทำให้คุณเป็นผู้จัดเก็บข้อมูลเพียงเครื่องเดียว นอกจากนี้คุณต้องเปิดใช้งานการแม็พอุปกรณ์ดิบ (RDM) ด้วยการใช้พื้นที่เก็บข้อมูลที่แบ่งใช้ ซึ่งหมายความว่าคุณจะสูญเสียสิทธิ์การเข้าถึงฟังก์ชัน VMware ที่มีประสิทธิภาพมากมายเช่น vMotion การกำหนดค่าคลัสเตอร์ที่แบ่งใช้ร่วมกันจะช่วยลดพื้นที่เก็บข้อมูลเป็น SPOF ในเวลาเดียวกันคุณยังสามารถใช้ vMotion เพื่อโยกย้าย VM ของคุณระหว่างโฮสต์ทางกายภาพ เป็น win-win! กลุ่มที่ใช้ร่วมกันไม่มีเลยก็เป็นโซลูชันที่ยอดเยี่ยมสำหรับการกู้คืนระบบเนื่องจากระบบสแตนด์บายสามารถอยู่ที่ศูนย์ข้อมูลอื่นได้

ครอบคลุมฐานทั้งหมด 

แอพพลิเคชัน – failover clustering ซึ่งแบ่งเป็นชั้นเหนือ VMware HA ให้บริการที่ดีที่สุดของทั้งสองโลก คุณสามารถเพลิดเพลินกับการปกป้องฮาร์ดแวร์และการรับรู้แอพพลิเคชันในตัวความยืดหยุ่นและความสามารถในการปรับขนาดได้มากขึ้นและเวลาในการกู้คืนข้อมูลที่รวดเร็วยิ่งขึ้น ดียิ่งขึ้นการแก้ปัญหาไม่จำเป็นต้องทำลายธนาคาร ต้องการทราบว่าการทำคลัสเตอร์ Failover ด้วย VMware ความพร้อมใช้งานสูงสามารถทำงานได้อย่างไร เช็คอินกับ SIOS ทำซ้ำโดยได้รับอนุญาตจาก LinuxClustering

Filed Under: ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์ Tagged With: failover clustering พร้อมด้วย vmware high availability

เพิ่มประสิทธิภาพการจำลองแบบสำหรับ Linux Clustering ด้วย Fusion-io

พฤศจิกายน 27, 2018 by Jason Aw Leave a Comment

เพิ่มประสิทธิภาพการจำลองแบบสำหรับ Linux Clustering ด้วย Fusion-io

เคล็ดลับเพื่อเพิ่มประสิทธิภาพการจำลองแบบสำหรับ Linux Clustering ด้วย Fusion-io

เมื่อคนส่วนใหญ่คิดถึงการตั้งค่าคลัสเตอร์เซิร์ฟเวอร์จะมีเซิร์ฟเวอร์มากกว่าสองเครื่องและ SAN หรือบางส่วนของที่เก็บข้อมูลที่แชร์กัน SAN มีค่าใช้จ่ายสูงมากและซับซ้อนในการติดตั้งและบำรุงรักษา นอกจากนี้ยังแสดงให้เห็นถึงเทคนิคที่เป็นไปได้ในจุดเดียวของความล้มเหลว (SPOF) ในสถาปัตยกรรมคลัสเตอร์ของคุณ ทุกวันนี้ผู้คนจำนวนมากหันไปหา บริษัท อย่าง Fusion-io พร้อมด้วย ioDrives ที่เร็วที่สุดเพื่อเร่งการใช้งานที่สำคัญ  อุปกรณ์จัดเก็บข้อมูลเหล่านี้นั่งอยู่ภายในเซิร์ฟเวอร์ (เช่นไม่ใช่ "ดิสก์ที่ใช้ร่วมกัน") ดังนั้นจึงไม่สามารถใช้เป็นดิสก์คลัสเตอร์กับโซลูชันการจัดกลุ่มแบบเดิม ๆ ได้ โชคดีที่มีวิธีเพิ่มประสิทธิภาพการจำลองแบบสำหรับ Linux Clustering ด้วย Fusion-io โซลูชันที่ช่วยให้คุณสามารถสร้างคลัสเตอร์ failover ได้เมื่อไม่มีที่เก็บข้อมูลที่ใช้ร่วมกันนั่นคือกลุ่ม "ไม่มีการแชร์อะไร"

กลุ่มแบบดั้งเดิม เพิ่มประสิทธิภาพการจำลองแบบสำหรับ Linux Clustering ด้วย Fusion-io - Cluster แบบดั้งเดิม  กลุ่ม "Shared Nothing"เพิ่มประสิทธิภาพการจำลองแบบสำหรับ Linux Clustering ด้วย Fusion-io - Shared Cluster

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

เครือข่าย

  • ใช้ 10Gbps NIC: อุปกรณ์จัดเก็บข้อมูลแบบ Flash จาก Fusion-io (หรือผลิตภัณฑ์อื่นที่คล้ายคลึงกันจาก OCZ, LSI และอื่น ๆ ) สามารถเขียนข้อมูลด้วยความเร็วใน HUNDREDS (750) MB / วินาทีหรือมากกว่า  NIC ขนาด 1Gbps สามารถดันสูงสุดได้ถึง 125 เมกะไบต์ต่อวินาทีดังนั้นทุกคนที่ใช้ประโยชน์จากศักยภาพของ ioDrive สามารถเขียนข้อมูลได้เร็วกว่าที่จะถูกผลักผ่านการเชื่อมต่อเครือข่าย 1 Gbps  เพื่อให้แน่ใจว่าคุณมีแบนด์วิธที่เพียงพอระหว่างเซิร์ฟเวอร์เพื่ออำนวยความสะดวกในการจำลองแบบข้อมูลแบบเรียลไทม์ควรใช้ NIC ขนาด 10 Gbps เพื่อรับข้อมูลการจำลองแบบ
  • เปิดใช้งานกรอบ Jumbo: สมมติว่าการ์ดเครือข่ายและสวิทช์ของคุณสนับสนุนการเปิดใช้งานเฟรม jumbo สามารถเพิ่มประสิทธิภาพการทำงานของเครือข่ายของคุณได้มากขึ้นในขณะเดียวกันก็ลดรอบการทำงานของ CPU  หากต้องการเปิดใช้งานเฟรม jumbo ให้ใช้การกำหนดค่าต่อไปนี้ (ตัวอย่างจากเซิร์ฟเวอร์ RedHat / CentOS / OEL linux)
    • ifconfig <interface_name> mtu 9000
    • แก้ไขไฟล์ / etc / sysconfig / network-scripts / ifcfg- <interface_name> และเพิ่ม "MTU = 9000" เพื่อให้การเปลี่ยนแปลงยังคงอยู่ในการเริ่มต้นใหม่
    • เมื่อต้องการตรวจสอบการดำเนินการของกรอบ jumbo แบบ end-to-end ให้เรียกใช้คำสั่งนี้: ping -s 8900 -M do <IP-of-other-server>
  • เปลี่ยนความยาวคิวส่งของ NIC:
    • / sbin / ifconfig <interface_name> txqueuelen 10000
    • เพิ่มข้อมูลนี้ใน /etc/rc.local เพื่อรักษาการตั้งค่าข้ามการเริ่มระบบใหม่

TCP / IP Tuning

  • เปลี่ยน netdev_max_backlog ของ NIC:
    • ตั้งค่า "net.core.netdev_max_backlog = 100000" ใน /etc/sysctl.conf
  • การปรับแต่ง TCP / IP อื่น ๆ ที่ได้รับการแสดงเพื่อเพิ่มประสิทธิภาพการจำลองแบบ:
    • หมายเหตุ: เป็นค่าตัวอย่างและอาจจำเป็นต้องปรับเปลี่ยนตามการกำหนดค่าฮาร์ดแวร์ของคุณ
    • แก้ไข /etc/sysctl.conf และเพิ่มพารามิเตอร์ต่อไปนี้:
      • net.core.rmem_default = 16777216
      • net.core.wmem_default = 16777216
      • net.core.rmem_max = 16777216
      • net.core.wmem_max = 16777216
      • net.ipv4.tcp_rmem = 4096 87380 16777216
      • net.ipv4.tcp_wmem = 4096 65536 16777216
      • net.ipv4.tcp_timestamps = 0
      • net.ipv4.tcp_sack = 0
      • net.core.optmem_max = 16777216
      • net.ipv4.tcp_congestion_control = HTCP

การปรับ

โดยปกติคุณจะต้องปรับเปลี่ยนการกำหนดค่าคลัสเตอร์ของคุณซึ่งจะแตกต่างกันไปขึ้นอยู่กับเทคโนโลยีการจัดกลุ่มและจำลองข้อมูลที่คุณตัดสินใจใช้  ในตัวอย่างนี้ฉันใช้ SteelEye Protection Suite สำหรับ Linux (SPS หรือ aka LifeKeeper) จาก SIOS Technologies จะช่วยให้ผู้ใช้สามารถสร้างกลุ่ม failover ที่ใช้ประโยชน์จากประเภทจัดเก็บข้อมูลแบบแบ็คเอนด์: Fibre Channel SAN, iSCSI, NAS หรือส่วนใหญ่ที่เกี่ยวข้องกับบทความนี้ดิสก์ในเครื่องที่ต้องมีการซิงโครไนซ์ / จำลองแบบเรียลไทม์ระหว่างโหนดคลัสเตอร์  SPS for Linux รวมถึงฟังก์ชันการทำสำเนาข้อมูลระดับบล็อคที่ทำให้การติดตั้งคลัสเตอร์เป็นเรื่องง่ายเมื่อไม่มีที่เก็บข้อมูลที่ใช้ร่วมกัน

ข้อเสนอแนะ

เพื่อเพิ่มประสิทธิภาพการจำลองแบบสำหรับ Linux Clustering ด้วย Fusion-io ให้มากที่สุดลองใช้วิธีนี้ SteelEye Protection Suite (SPS) สำหรับคำแนะนำการกำหนดค่า Linux:

  • จัดสรรพาร์ติชันดิสก์ขนาดเล็ก (~ 100 MB) ที่อยู่ในไดรฟ์ Fusion-io เพื่อวางไฟล์บิตแมป  สร้างระบบแฟ้มบนพาร์ติชันนี้และติดตั้งตัวอย่างเช่นที่ / bitmap:
    • # mount | grep / bitmap
    • / dev / fioa1 on / ประเภทบิตแมป ext3 (rw)
  • ก่อนที่จะสร้างกระจกของคุณปรับพารามิเตอร์ต่อไปนี้ใน / etc / default / LifeKeeper
    • แทรก: LKDR_CHUNK_SIZE = 4096
      • ค่าดีฟอลต์คือ 64
    • แก้ไข: LKDR_SPEED_LIMIT = 1500000
      • (ค่าเริ่มต้นคือ 50000)
      • LKDR_SPEED_LIMIT ระบุแบนด์วิดท์สูงสุดที่ resync จะใช้เวลา – ควรตั้งค่าสูงพอที่จะทำให้ resyncs ไปที่ความเร็วสูงสุดเท่าที่จะเป็นไปได้
    • แก้ไข: LKDR_SPEED_LIMIT_MIN = 200000
      • (ค่าดีฟอลต์คือ 20000)
      • LKDR_SPEED_LIMIT_MIN ระบุความเร็วที่ควรจะได้รับอนุญาตให้ทำซ้ำเมื่อมี I / O อื่น ๆ เกิดขึ้นพร้อม ๆ กัน – ตามกฎของหัวแม่มือนี้ควรตั้งค่าให้เขียนได้ไม่เกินครึ่งหรือน้อยกว่าเพื่อหลีกเลี่ยงความอดอยาก ออกกิจกรรม I / O ตามปกติเมื่อเกิดการ resync

จากนี้ไปข้างหน้าและสร้างกระจกเงาของคุณและกำหนดค่าคลัสเตอร์ตามปกติ สนใจที่จะเพิ่มประสิทธิภาพการจำลองแบบสูงสุดสำหรับการทำคลัสเตอร์ Linux ด้วย Fusion-io ดูว่า SIOS สามารถให้อะไรได้อีก ทำซ้ำโดยได้รับอนุญาตจาก LinuxClustering

Filed Under: Datakeeper, ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์ Tagged With: Fusion-io, การทำซ้ำ, ลินุกซ์, เพิ่มประสิทธิภาพการจำลองแบบสำหรับการจัดกลุ่ม linux ด้วย io แบบฟิวชั่น

  • « Previous Page
  • 1
  • …
  • 83
  • 84
  • 85
  • 86
  • 87
  • …
  • 112
  • Next Page »

โพสต์ล่าสุด

  • ระบบความพร้อมใช้งานสูง (High Availability หรือ HA) คืออะไร?
  • เอาตัวรอดจากวิกฤตการณ์วันศุกร์: จากระบบคอมพิวเตอร์แบบดิบๆ สู่การจำลองข้อมูลที่ราบรื่น
  • ติดดิน: สิ่งที่การพลาดชม Percona Live Amsterdam สอนฉันเกี่ยวกับ HA
  • เปรียบเทียบ SIOS LifeKeeper กับ Red Hat High Availability Add-On:
  • สถานะของความยืดหยุ่นของแอปพลิเคชัน: ผลสำรวจความพร้อมใช้งานสูงของ SIOS ปี 2026

กระทู้ยอดนิยม

เข้าร่วมรายชื่อผู้รับจดหมายของเรา

Copyright © 2026 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in