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
  • ไทย

Archives for กันยายน 2021

การปรับใช้อินสแตนซ์คลัสเตอร์ล้มเหลวของเซิร์ฟเวอร์ SQL บน Huawei Cloud

กันยายน 28, 2021 by Jason Aw Leave a Comment

ECS IaaS . ความพร้อมใช้งานสูงของ Huawei Cloud

* การปฏิเสธความรับผิด: แม้ว่าข้อมูลต่อไปนี้จะครอบคลุมส่วนความพร้อมใช้งานสูงภายในขอบเขตของผลิตภัณฑ์ของเราอย่างสมบูรณ์ แต่นี่เป็น “คู่มือ” ในการตั้งค่าเท่านั้นและควรปรับให้เข้ากับการกำหนดค่าของคุณเอง

ภาพรวม HUAWEI Cloud เป็นผู้ให้บริการคลาวด์ชั้นนำที่ไม่เพียงแต่ในประเทศจีนเท่านั้น แต่ยังมีพื้นที่ทั่วโลกด้วยศูนย์ข้อมูลหลายแห่งทั่วโลก พวกเขานำความเชี่ยวชาญกว่า 30 ปีของ Huawei มารวมกันในผลิตภัณฑ์และโซลูชันโครงสร้างพื้นฐาน ICT และมุ่งมั่นที่จะให้บริการคลาวด์ที่เชื่อถือได้ ปลอดภัย และคุ้มค่า เพื่อเพิ่มขีดความสามารถของแอปพลิเคชัน ควบคุมพลังของข้อมูล และช่วยให้องค์กรทุกขนาดเติบโตในยุคปัจจุบัน โลกที่ชาญฉลาด HUAWEI CLOUD มุ่งมั่นที่จะนำเสนอบริการคลาวด์และ AI ที่มีราคาไม่แพง มีประสิทธิภาพ และเชื่อถือได้ผ่านนวัตกรรมทางเทคโนโลยี

DataKeeper Cluster Edition ให้การจำลองแบบในระบบคลาวด์ส่วนตัวเสมือน (VPC) ภายในภูมิภาคเดียวในโซนความพร้อมใช้งานสำหรับคลาวด์ของ Huawei ในตัวอย่างการทำคลัสเตอร์ SQL Server นี้ เราจะเปิดใช้อินสแตนซ์สี่อินสแตนซ์ (อินสแตนซ์ตัวควบคุมโดเมนหนึ่งอินสแตนซ์ อินสแตนซ์ SQL Server สองอินสแตนซ์ และอินสแตนซ์องค์ประชุม/อินสแตนซ์) ในโซนความพร้อมใช้งานสามโซน

สถาปัตยกรรม Huawei Cloud SIOS Datakeeper HA

DataKeeper Cluster Edition ให้การสนับสนุนโหนดการจำลองข้อมูลภายนอกคลัสเตอร์ที่มีโหนดทั้งหมดในคลาวด์ของ Huawei ในตัวอย่างการทำคลัสเตอร์ SQL Server โดยเฉพาะนี้ อินสแตนซ์สี่ตัวถูกเปิดใช้ (อินสแตนซ์ตัวควบคุมโดเมนหนึ่งอินสแตนซ์ อินสแตนซ์ SQL Server สองอินสแตนซ์ และอินสแตนซ์องค์ประชุม/อินสแตนซ์) ในโซนความพร้อมใช้งานสามโซน จากนั้นจะมีการเปิดตัวอินสแตนซ์ DataKeeper เพิ่มเติมในภูมิภาคที่สอง รวมถึงอินสแตนซ์ VPN ในทั้งสองภูมิภาค โปรดมอง การกำหนดค่าการจำลองข้อมูลจากโหนดคลัสเตอร์ไปยังไซต์ DR ภายนอก สำหรับข้อมูลเพิ่มเติม. สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการใช้หลายภูมิภาค โปรดดูที่ การเชื่อมต่อ VPC สองเครื่องในภูมิภาคต่างๆ .

สถาปัตยกรรม Huawei Cloud SIOS Datakeeper DR

DataKeeper Cluster Edition ยังรองรับโหนดการจำลองข้อมูลภายนอกคลัสเตอร์ที่มีเฉพาะโหนดภายนอกคลัสเตอร์ใน Huawei Cloud ในตัวอย่างการทำคลัสเตอร์ SQL Server โดยเฉพาะ WSFC1 และ WSFC2 อยู่ในคลัสเตอร์ในไซต์ที่จำลองแบบไปยังอินสแตนซ์ Huawei Cloud จากนั้นจะมีการเปิดตัวอินสแตนซ์ DataKeeper เพิ่มเติมในภูมิภาคใน Huawei Cloud โปรดมอง การกำหนดค่าการจำลองข้อมูลจากโหนดคลัสเตอร์ไปยังไซต์ DR ภายนอก สำหรับข้อมูลเพิ่มเติม.

สถาปัตยกรรม Huawei Cloud SIOS Datakeeper Hybrid DR

ความต้องการ

คำอธิบาย ความต้องการ
คลาวด์ส่วนตัวเสมือน ในภูมิภาคเดียวที่มีสามโซนความพร้อมใช้งาน
ประเภทอินสแตนซ์ ประเภทอินสแตนซ์ที่แนะนำขั้นต่ำ: s3.large.2
ระบบปฏิบัติการ ดูเมทริกซ์การสนับสนุน DKCE
IP ยืดหยุ่น ที่อยู่ IP แบบยืดหยุ่นหนึ่งรายการเชื่อมต่อกับตัวควบคุมโดเมน
สี่กรณี หนึ่งอินสแตนซ์ตัวควบคุมโดเมน สองอินสแตนซ์ของ SQL Server และหนึ่งองค์ประชุม/อินสแตนซ์ของพยาน
SQL Server แต่ละตัว ENI (Elastic Network Interface) ที่มี 4 IP · ENI IP หลักที่กำหนดไว้แบบคงที่ใน Windows และใช้โดย DataKeeper Cluster Edition · IP สามรายการที่ดูแลโดย ECS ในขณะที่ใช้โดย Windows Failover Clustering , DTC และ SQLFC
ปริมาณ สามวอลุ่ม (EBS และ NTFS เท่านั้น) · หนึ่งวอลุ่มหลัก (ไดรฟ์ C) · สองวอลุ่มเพิ่มเติม o หนึ่งสำหรับการทำคลัสเตอร์ล้มเหลว o หนึ่งสำหรับ MSDTC

บันทึกประจำรุ่น ก่อนจะเริ่ม อย่าลืมอ่าน บันทึกประจำรุ่น DataKeeper Cluster Edition สำหรับข้อมูลล่าสุด ขอแนะนำให้อ่านและทำความเข้าใจ คู่มือการติดตั้ง DataKeeper Cluster Edition .

สร้าง Virtual Private Cloud (VPC) คลาวด์ส่วนตัวเสมือนเป็นอ็อบเจ็กต์แรกที่คุณสร้างเมื่อใช้ DataKeeper Cluster Edition

* Virtual Private Cloud (VPC) คือไพรเวทคลาวด์แบบแยกส่วน ซึ่งประกอบด้วยพูลทรัพยากรการประมวลผลที่ใช้ร่วมกันที่กำหนดค่าได้ในระบบคลาวด์สาธารณะ

  1. ใช้อีเมลและรหัสผ่านที่ระบุตอนสมัคร Huawei Cloud , ลงชื่อเข้าใช้ Huawei Cloud Management Console .
  2. จาก บริการ ดรอปดาวน์ เลือก คลาวด์ส่วนตัวเสมือน .

  1. ที่ด้านขวาของหน้าจอ ให้คลิกที่ สร้าง VPC และเลือกภูมิภาคที่คุณต้องการใช้
  2. ป้อนชื่อที่คุณต้องการใช้สำหรับ VPC
  3. กำหนดซับเน็ตคลาวด์ส่วนตัวเสมือนของคุณโดยป้อน your CIDR (การกำหนดเส้นทางระหว่างโดเมนแบบไม่มีคลาส) ตามที่อธิบายไว้ด้านล่าง
  4. ป้อนชื่อซับเน็ต จากนั้นคลิก สร้างตอนนี้ .

* ตารางเส้นทางจะถูกสร้างขึ้นโดยอัตโนมัติด้วยการเชื่อมโยง “หลัก” กับ VPC ใหม่ คุณสามารถใช้ในภายหลังหรือสร้างตารางเส้นทางอื่น

* ลิงค์ที่เป็นประโยชน์: Huawei’s การสร้าง Virtual Private Cloud (VPC) เปิดตัวอินสแตนซ์ ข้อมูลต่อไปนี้จะแนะนำคุณเกี่ยวกับการเปิดใช้อินสแตนซ์ในซับเน็ตของคุณ คุณจะต้องเปิดใช้อินสแตนซ์สองอินสแตนซ์ในโซนความพร้อมใช้งานเดียว อินสแตนซ์หนึ่งสำหรับอินสแตนซ์ตัวควบคุมโดเมน และอีกรายการสำหรับอินสแตนซ์ SQL ของคุณ จากนั้น คุณจะเปิดใช้อินสแตนซ์ SQL อื่นในโซนความพร้อมใช้งานอื่น และอินสแตนซ์ขององค์ประชุมในโซนความพร้อมใช้งานอื่น

* ลิงก์ที่มีประโยชน์: อินสแตนซ์ Huawei Cloud ECS

  1. ใช้อีเมลและรหัสผ่านที่ระบุตอนสมัคร Huawei Cloud , ลงชื่อเข้าใช้ Huawei Cloud Management Console .
  2. จาก รายการบริการ ดรอปดาวน์ เลือก เซิร์ฟเวอร์คลาวด์ยืดหยุ่น .

  1. เลือก ซื้อ ECS และเลือกโหมดการเรียกเก็บเงิน ภูมิภาค และ AZ (Availability Zone) เพื่อปรับใช้ Instance
  2. เลือกประเภทอินสแตนซ์ของคุณ ( บันทึก: เลือก s3.large.2 หรือใหญ่กว่า)
  3. เลือกรูปภาพ ภายใต้ รูปภาพสาธารณะ ให้เลือก Windows Server 2019 Datacenter 64bit ภาษาอังกฤษ ภาพ
    1. สำหรับ กำหนดค่าเครือข่าย เลือก VPC ของคุณ
    2. สำหรับ ซับเน็ต , เลือก Subnet ที่คุณต้องการใช้ เลือก ที่อยู่ IP ที่ระบุด้วยตนเอง และป้อนที่อยู่ IP ที่คุณต้องการใช้
    3. เลือก กลุ่มรักษาความปลอดภัย เพื่อใช้หรือแก้ไขและเลือกที่มีอยู่
    4. กำหนด EIP หากคุณต้องการอินสแตนซ์ ECS เพื่อเข้าถึงอินเทอร์เน็ต
    5. คลิก กำหนดการตั้งค่าขั้นสูง และตั้งชื่อให้ ECS ใช้ รหัสผ่าน สำหรับ โหมดเข้าสู่ระบบ และระบุรหัสผ่านที่ปลอดภัยสำหรับการเข้าสู่ระบบของผู้ดูแลระบบ
    6. คลิก กำหนดค่าตอนนี้ บน ตัวเลือกขั้นสูง เพิ่ม แท็ก เพื่อตั้งชื่ออินสแตนซ์ของคุณและคลิกที่ ยืนยัน
  4. ดำเนินการตรวจสอบอินสแตนซ์ขั้นสุดท้ายแล้วคลิก ส่ง .

* สำคัญ: จดบันทึกรหัสผ่านผู้ดูแลระบบเริ่มต้นนี้ จำเป็นต้องเข้าสู่ระบบอินสแตนซ์ของคุณ

ทำซ้ำขั้นตอนข้างต้นสำหรับอินสแตนซ์ทั้งหมด

เชื่อมต่อกับอินสแตนซ์ คุณสามารถเชื่อมต่อกับอินสแตนซ์ตัวควบคุมโดเมนของคุณผ่าน เข้าสู่ระบบระยะไกล จากบานหน้าต่าง ECS

เข้าสู่ระบบในฐานะผู้ดูแลระบบและป้อนของคุณ รหัสผ่านผู้ดูแลระบบ .

* ปฏิบัติที่ดีที่สุด: เมื่อเข้าสู่ระบบแล้ว ควรเปลี่ยนรหัสผ่านของคุณ

กำหนดค่าอินสแตนซ์ตัวควบคุมโดเมน เมื่อสร้างอินสแตนซ์แล้ว เราเริ่มต้นด้วยการตั้งค่าอินสแตนซ์บริการโดเมน

คู่มือนี้ไม่ใช่บทช่วยสอนเกี่ยวกับวิธีตั้งค่าอินสแตนซ์เซิร์ฟเวอร์ Active Domain เราแนะนำให้อ่าน บทความ เกี่ยวกับวิธีการตั้งค่าและกำหนดค่าเซิร์ฟเวอร์ Active Directory สิ่งสำคัญคือต้องเข้าใจว่าแม้ว่าอินสแตนซ์จะทำงานในคลาวด์ของ Huawei แต่นี่เป็นการติดตั้ง Active Directory เป็นประจำ

ที่อยู่ IP แบบคงที่ กำหนดค่าที่อยู่ IP แบบคงที่สำหรับอินสแตนซ์ของคุณ

  1. เชื่อมต่อกับอินสแตนซ์ตัวควบคุมโดเมนของคุณ
  2. คลิก เริ่ม / แผงควบคุม .
  3. คลิก ศูนย์เครือข่ายและการแบ่งปัน .
  4. เลือกอินเทอร์เฟซเครือข่ายของคุณ
  5. คลิก คุณสมบัติ .
  6. คลิก อินเทอร์เน็ตโปรโตคอลเวอร์ชัน 4 (TCP/IPv4) , แล้ว คุณสมบัติ .
  7. รับปัจจุบันของคุณ ที่อยู่ IPv4 , เกตเวย์เริ่มต้น และ เซิร์ฟเวอร์ DNS สำหรับอินเทอร์เฟซเครือข่ายจาก อเมซอน .
  8. ใน คุณสมบัติอินเทอร์เน็ตโปรโตคอลเวอร์ชัน 4 (TCP/IPv4) กล่องโต้ตอบ ภายใต้ ใช้ที่อยู่ IP ต่อไปนี้ , ใส่ของคุณ ที่อยู่ IPv4 .
  9. ใน ซับเน็ตมาสก์ ให้พิมพ์ซับเน็ตมาสก์ที่เชื่อมโยงกับซับเน็ตคลาวด์ส่วนตัวเสมือนของคุณ
  10. ใน เกตเวย์เริ่มต้น กล่อง พิมพ์ ที่อยู่ IP ของเกตเวย์เริ่มต้นแล้วคลิก ตกลง .
  11. สำหรับ เซิร์ฟเวอร์ DNS ที่ต้องการ , ป้อน ที่อยู่ IP หลักของตัวควบคุมโดเมนของคุณ (เช่น 15.0.1.72)
  12. คลิก ตกลง จากนั้นเลือก ปิด I . ทางออก ศูนย์เครือข่ายและการแบ่งปัน .
  13. ทำซ้ำขั้นตอนข้างต้นกับอินสแตนซ์อื่นๆ ของคุณ

เข้าร่วมสองอินสแตนซ์ SQL และอินสแตนซ์พยานในโดเมน * ก่อนที่จะพยายามเข้าร่วมโดเมน ให้ทำการปรับเครือข่ายเหล่านี้ บนอะแดปเตอร์เครือข่ายของคุณ เพิ่ม/เปลี่ยนเซิร์ฟเวอร์ DNS ที่ต้องการเป็นที่อยู่ Domain Controller ใหม่และเซิร์ฟเวอร์ DNS ใช้ ipconfig /flushdns เพื่อรีเฟรชรายการค้นหา DNS หลังจากการเปลี่ยนแปลงนี้ ทำสิ่งนี้ก่อนพยายามเข้าร่วมโดเมน

* รับรองว่า เครือข่ายหลัก และ การแชร์ไฟล์และเครื่องพิมพ์ ตัวเลือกได้รับอนุญาตในไฟร์วอลล์ Windows

  1. ในแต่ละกรณี คลิก เริ่ม จากนั้นคลิกขวา คอมพิวเตอร์ และเลือก คุณสมบัติ .
  2. ที่ด้านขวาสุด เลือก เปลี่ยนการตั้งค่า .
  3. คลิกที่ เปลี่ยน .
  4. ใส่ใหม่ ชื่อคอมพิวเตอร์ .
  5. เลือก โดเมน .
  6. เข้า ชื่อโดเมน – (เช่น docs.huawei.com)
  7. คลิก นำมาใช้ .

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

* ปฏิบัติที่ดีที่สุด: ขอแนะนำให้ตั้งค่าไฟล์หน้าระบบเป็น ระบบจัดการ (ไม่อัตโนมัติ) และใช้ไดรฟ์ C: เสมอ

แผงควบคุม > การตั้งค่าระบบขั้นสูง > ประสิทธิภาพ > การตั้งค่า > ขั้นสูง > หน่วยความจำเสมือน เลือก ขนาดที่จัดการโดยระบบ , ปริมาณ C: เท่านั้น จากนั้นเลือก ชุด เพื่อบันทึก.

กำหนด IP ส่วนตัวรองให้กับอินสแตนซ์ SQL สองอินสแตนซ์ นอกจาก IP หลักแล้ว คุณจะต้องเพิ่ม IP เพิ่มเติมสามตัว (IP รอง) ให้กับอินเทอร์เฟซเครือข่ายแบบยืดหยุ่นสำหรับอินสแตนซ์ SQL แต่ละรายการ

  1. จาก รายการบริการ ดรอปดาวน์ เลือก เซิร์ฟเวอร์คลาวด์ยืดหยุ่น .
  2. คลิกอินสแตนซ์ที่คุณต้องการเพิ่มที่อยู่ IP ส่วนตัวสำรอง
  3. เลือก NIC > จัดการที่อยู่ IP เสมือน .
  4. คลิกที่ กำหนดที่อยู่ IP เสมือน และเลือก คู่มือ ป้อนที่อยู่ IP ที่อยู่ภายในช่วงซับเน็ตสำหรับอินสแตนซ์ (เช่น สำหรับ 15.0.1.25 ให้ป้อน 15.0.1.26) คลิก ตกลง .
  5. คลิกที่ มากกว่า ดรอปดาวน์บนแถวที่อยู่ IP แล้วเลือก ผูกกับเซิร์ฟเวอร์ เลือกเซิร์ฟเวอร์ที่จะผูกที่อยู่ IP และการ์ด NIC
  6. คลิก ตกลง เพื่อบันทึกงานของคุณ
  7. ดำเนินการด้านบนบน ทั้งอินสแตนซ์ SQL .

* ลิงก์ที่มีประโยชน์: การจัดการที่อยู่ IP เสมือน การผูกที่อยู่ IP เสมือนกับ EIP หรือ ECS สร้างและแนบวอลุ่ม DataKeeper เป็นโซลูชันการจำลองแบบโวลุ่มระดับบล็อก และต้องการให้แต่ละโหนดในคลัสเตอร์มีโวลุ่มเพิ่มเติม (นอกเหนือจากไดรฟ์ระบบ) ที่มีขนาดเท่ากันและมีอักษรระบุไดรฟ์เหมือนกัน โปรดตรวจสอบ การพิจารณาปริมาณ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับข้อกำหนดในการจัดเก็บ

สร้างเล่ม สร้างสองวอลุ่มในแต่ละโซนความพร้อมใช้งานสำหรับอินสแตนซ์เซิร์ฟเวอร์ SQL แต่ละรายการ รวมเป็นสี่วอลุ่ม

  1. จาก รายการบริการ ดรอปดาวน์ เลือก เซิร์ฟเวอร์คลาวด์ยืดหยุ่น .
  2. คลิกอินสแตนซ์ที่คุณต้องการจัดการ
  3. ไปที่ ดิสก์ แท็บ
  4. คลิก เพิ่มดิสก์ หากต้องการเพิ่มโวลุ่มและขนาดใหม่ที่คุณเลือก ตรวจสอบให้แน่ใจว่าคุณได้เลือกโวลุ่มใน AZ เดียวกันกับเซิร์ฟเวอร์ SQL ที่คุณต้องการแนบ
  5. เลือกช่องทำเครื่องหมายเพื่อยอมรับ SLA และ ส่ง
  6. คลิก กลับไปที่คอนโซลเซิร์ฟเวอร์
  7. แนบ ดิสก์หากจำเป็นสำหรับอินสแตนซ์ SQL
  8. ทำเช่นนี้สำหรับทั้งสี่เล่ม

* ลิงก์ที่มีประโยชน์: บริการปริมาณยืดหยุ่น กำหนดค่าคลัสเตอร์ ก่อนที่จะติดตั้ง DataKeeper Cluster Edition สิ่งสำคัญคือต้องมี Windows Server ที่กำหนดค่าเป็นคลัสเตอร์โดยใช้โหนดส่วนใหญ่ควอรัม (หากมีโหนดเป็นจำนวนคี่) หรือโควรัมส่วนใหญ่ที่แชร์โหนดและไฟล์ (หากมีจำนวนคู่ โหนด) ศึกษาเอกสารประกอบของ Microsoft เกี่ยวกับการจัดกลุ่มเพิ่มเติมจากหัวข้อนี้สำหรับคำแนะนำทีละขั้นตอนบันทึก: Microsoft เปิดตัว a โปรแกรมแก้ไขด่วน สำหรับ Windows 2008R2 ที่อนุญาตให้ปิดใช้งานการลงคะแนนของโหนด ซึ่งอาจช่วยให้มีความพร้อมใช้งานในระดับที่สูงขึ้นในการกำหนดค่าคลัสเตอร์หลายไซต์บางรายการ

เพิ่ม Failover Clustering เพิ่มฟีเจอร์ Failover Clustering ให้กับอินสแตนซ์ SQL ทั้งสอง

  1. ปล่อย ตัวจัดการเซิร์ฟเวอร์ .
  2. เลือก คุณสมบัติ ในบานหน้าต่างด้านซ้ายและคลิก เพิ่มคุณสมบัติ ใน คุณสมบัติ นี้เริ่มต้น เพิ่มตัวช่วยสร้างคุณสมบัติ .
  3. เลือก คลัสเตอร์ล้มเหลว .
  4. เลือก ติดตั้ง .

ตรวจสอบการกำหนดค่า

  1. เปิด ตัวจัดการคลัสเตอร์ล้มเหลว .
  2. เลือก Failover Cluster Manager เลือก ตรวจสอบการกำหนดค่า .
  3. คลิก ต่อไป แล้วเพิ่มสองของคุณ อินสแตนซ์ SQL .

บันทึก: หากต้องการค้นหา ให้เลือก เรียกดู จากนั้นคลิกที่ ขั้นสูง และ ค้นหาตอนนี้ . นี่จะแสดงรายการอินสแตนซ์ที่พร้อมใช้งาน

  1. คลิก ต่อไป .
  2. เลือก เรียกใช้การทดสอบเท่านั้นที่ฉันเลือก และคลิก ต่อไป .
  3. ใน การเลือกการทดสอบ หน้าจอ ยกเลิกการเลือก พื้นที่จัดเก็บ และคลิก ต่อไป .
  4. ที่หน้าจอยืนยันผลลัพธ์ คลิก ต่อไป .
  5. ทบทวน รายงานสรุปการตรวจสอบ แล้วคลิก เสร็จสิ้น .

สร้างคลัสเตอร์

  1. ใน ตัวจัดการคลัสเตอร์ล้มเหลว , คลิกที่ สร้างคลัสเตอร์ แล้วคลิก ต่อไป .
  2. ใส่สองของคุณ อินสแตนซ์ SQL .
  3. บน คำเตือนการตรวจสอบความถูกต้อง หน้าเลือก เลขที่ แล้วคลิก ต่อไป .
  4. บน จุดเข้าใช้งานสำหรับการจัดการคลัสเตอร์ ให้ป้อนชื่อเฉพาะสำหรับคลัสเตอร์ WSFC ของคุณ จากนั้นป้อน ที่อยู่ IP ของคลัสเตอร์ล้มเหลว สำหรับแต่ละโหนดที่เกี่ยวข้องในคลัสเตอร์ นี่เป็นครั้งแรกในสาม ที่อยู่ IP สำรอง เพิ่มก่อนหน้านี้ในแต่ละอินสแตนซ์
  5. สำคัญ! ยกเลิกการเลือกช่องทำเครื่องหมาย “เพิ่มที่เก็บข้อมูลที่มีอยู่ทั้งหมดไปยังคลัสเตอร์” ไดรฟ์ที่ทำมิเรอร์ DataKeeper ต้องไม่ได้รับการจัดการโดยกำเนิดโดยคลัสเตอร์ พวกเขาจะได้รับการจัดการเป็น DataKeeper Volumes
  6. คลิก ต่อไป บน การยืนยัน
  7. บน สรุป หน้า ตรวจทานคำเตือนใด ๆ จากนั้นเลือก เสร็จสิ้น .

กำหนดค่าองค์ประชุม/พยาน

  1. สร้างโฟลเดอร์บนอินสแตนซ์องค์ประชุม/พยานของคุณ (พยาน)
  2. แชร์โฟลเดอร์
    1. คลิกขวาที่โฟลเดอร์และเลือก แบ่งปันกับ / เฉพาะบุคคล ….
    2. จากดรอปดาวน์ ให้เลือก ทุกคน และคลิก เพิ่ม .
    3. ภายใต้ ระดับการอนุญาต , เลือก อ่านเขียน .
    4. คลิก แบ่งปัน , แล้ว เสร็จแล้ว . (จดบันทึกเส้นทางของการแชร์ไฟล์นี้เพื่อใช้ด้านล่าง)
  3. ใน ตัวจัดการคลัสเตอร์ล้มเหลว , คลิกขวาที่คลัสเตอร์แล้วเลือก การดำเนินการมากขึ้น และ กำหนดการตั้งค่าองค์ประชุมคลัสเตอร์ . คลิก ต่อไป .
  4. บน เลือกการกำหนดค่าองค์ประชุม , เลือก โหนดและไฟล์แชร์ส่วนใหญ่ และคลิก ต่อไป .
  5. บน กำหนดค่าพยานแชร์ไฟล์ ให้ป้อนเส้นทางไปยังไฟล์ที่แชร์ที่สร้างไว้ก่อนหน้านี้แล้วคลิก ต่อไป .
  6. บน การยืนยัน หน้าคลิก ต่อไป .
  7. บน สรุป หน้าคลิก เสร็จสิ้น .

ติดตั้งและกำหนดค่า DataKeeper หลังจากกำหนดค่าคลัสเตอร์พื้นฐานแล้ว แต่ก่อนที่จะสร้างทรัพยากรคลัสเตอร์ใดๆ ให้ติดตั้งและให้สิทธิ์ใช้งาน DataKeeper Cluster Edition บนโหนดคลัสเตอร์ทั้งหมด ดู คู่มือการติดตั้ง DataKeeper Cluster Edition สำหรับคำแนะนำโดยละเอียด

  1. วิ่ง การตั้งค่า DataKeeper ติดตั้ง DataKeeper Cluster Edition บนอินสแตนซ์ SQL ทั้งสอง
  2. ใส่ของคุณ คีย์ใบอนุญาต และรีบูตเมื่อได้รับแจ้ง
  3. เปิดตัว DataKeeper GUI และ เชื่อมต่อกับเซิร์ฟเวอร์ .

* บันทึก : ต้องเพิ่มบัญชีโดเมนหรือเซิร์ฟเวอร์ที่ใช้ในกลุ่มผู้ดูแลระบบภายใน บัญชีต้องมีสิทธิ์ของผู้ดูแลระบบในแต่ละเซิร์ฟเวอร์ที่ติดตั้ง DataKeeper อ้างถึง บริการ DataKeeper เข้าสู่ระบบ ID และการเลือกรหัสผ่าน สำหรับข้อมูลเพิ่มเติม

  1. คลิกขวาที่ งาน และเชื่อมต่อกับเซิร์ฟเวอร์ SQL ทั้งสอง
  2. สร้างงาน สำหรับแต่ละกระจกที่คุณจะสร้างขึ้น หนึ่งรายการสำหรับทรัพยากร DTC ของคุณและอีกรายการสำหรับทรัพยากร SQL ของคุณ..
  3. เมื่อระบบถามว่าคุณต้องการลงทะเบียนโวลุ่มอัตโนมัติเป็นโวลุ่มคลัสเตอร์หรือไม่ ให้เลือก ใช่ .

* บันทึก: หากติดตั้ง DataKeeper Cluster Edition บน Windows “Core” (Windows ที่ไม่มี GUI) โปรดอ่าน การติดตั้งและใช้งาน DataKeeper บน Windows 2008R2/2012 Server Core Platforms สำหรับคำแนะนำโดยละเอียด

กำหนดค่า MSDTC

  1. สำหรับ Windows Server 2012 และ 2016 ใน GUI ตัวจัดการคลัสเตอร์ล้มเหลว , เลือก บทบาท จากนั้นเลือก กำหนดค่าบทบาท .
  2. เลือก ผู้ประสานงานธุรกรรมแบบกระจาย (DTC) และคลิก ต่อไป .

* สำหรับ Windows Server 2008 ใน GUI ตัวจัดการคลัสเตอร์ล้มเหลว , เลือก บริการและแอพพลิเคชั่น จากนั้นเลือก กำหนดค่าบริการหรือแอปพลิเคชัน และคลิก ต่อไป .

  1. บน จุดเข้าใช้งานไคลเอ็นต์ หน้าจอ ป้อนชื่อ จากนั้นป้อน ที่อยู่ IP MSDTC สำหรับแต่ละโหนดที่เกี่ยวข้องในคลัสเตอร์ นี่คือที่สองในสาม ที่อยู่ IP สำรอง เพิ่มก่อนหน้านี้ในแต่ละอินสแตนซ์ คลิก ต่อไป .
  2. เลือก ปริมาณ MSDTC และคลิก ต่อไป .
  3. บน การยืนยัน หน้าคลิก ต่อไป .
  4. เมื่อ สรุป แสดงหน้า คลิก เสร็จสิ้น .

ติดตั้ง SQL บนอินสแตนซ์ SQL ตัวแรก

  1. บนเซิร์ฟเวอร์ตัวควบคุมโดเมน ให้สร้างโฟลเดอร์และแชร์..
    1. ตัวอย่างเช่น “TEMPSHARE” โดยได้รับอนุญาตจากทุกคน
  2. สร้างโฟลเดอร์ย่อย “SQL” และคัดลอกตัวติดตั้ง SQL .iso ลงในโฟลเดอร์ย่อยนั้น
  3. บนเซิร์ฟเวอร์ SQL ให้สร้างไดรฟ์เครือข่ายและแนบกับโฟลเดอร์ที่ใช้ร่วมกันบนตัวควบคุมโดเมน
    • . ตัวอย่างเช่น “การใช้เน็ต S: \TEMPSHARE
  4. บนเซิร์ฟเวอร์ SQL ไดรฟ์ S: จะปรากฏขึ้น ซีดีไปยังโฟลเดอร์ SQL และค้นหาตัวติดตั้ง SQL .iso คลิกขวาที่ไฟล์ .iso แล้วเลือก ภูเขา . ตัวติดตั้ง setup.exe จะปรากฏขึ้นพร้อมกับตัวติดตั้ง SQL .iso

F:>ตั้งค่า /SkipRules=Cluster_VerifyForErrors /Action=InstallFailoverCluster

  1. บน ตั้งค่ากฎการสนับสนุน , คลิก ตกลง .
  2. บน รหัสสินค้า โต้ตอบ ป้อนของคุณ รหัสสินค้า และคลิก ต่อไป .
  3. บน เงื่อนไขใบอนุญาต โต้ตอบ ยอมรับ ข้อตกลง และคลิก ต่อไป .
  4. บน อัพเดทสินค้า โต้ตอบ คลิก ต่อไป .
  5. บน ตั้งค่าไฟล์สนับสนุน โต้ตอบ คลิก ติดตั้ง .
  6. บน ตั้งค่ากฎการสนับสนุน โต้ตอบ คุณจะได้รับคำเตือน คลิก ต่อไป ละเว้นข้อความนี้ เนื่องจากเป็นที่คาดหมายในคลัสเตอร์การจัดเก็บข้อมูลแบบหลายไซต์หรือแบบไม่แบ่งใช้
  7. ตรวจสอบ การกำหนดค่าโหนดคลัสเตอร์ และคลิก ต่อไป .
  8. กำหนดค่า .ของคุณ เครือข่ายคลัสเตอร์ โดยเพิ่มที่อยู่ IP รอง “ที่สาม” สำหรับอินสแตนซ์ SQL ของคุณและคลิก ต่อไป . คลิก ใช่ เพื่อดำเนินการกำหนดค่าหลายซับเน็ต
  9. เข้า รหัสผ่าน สำหรับบัญชีบริการและคลิก ต่อไป .
  10. บน การรายงานข้อผิดพลาด โต้ตอบ คลิก ต่อไป .
  11. บน เพิ่มกฎโหนด ไดอะล็อก คำเตือนการทำงานที่ข้ามไปสามารถละเว้นได้ คลิก ต่อไป .
  12. ตรวจสอบคุณสมบัติและคลิก ติดตั้ง .
  13. คลิก ปิด I เพื่อสิ้นสุดขั้นตอนการติดตั้ง

ติดตั้ง SQL บนอินสแตนซ์ SQL ที่สอง การติดตั้งอินสแตนซ์ SQL ที่สองจะคล้ายกับอินสแตนซ์แรก

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

ตั้งค่า /SkipRules=Cluster_VerifyForErrors /Action=AddNode /INSTANCENAME=”MSSQLSERVER” ( บันทึก : นี่ถือว่าคุณติดตั้งอินสแตนซ์เริ่มต้นบนโหนดแรก)

  1. บน ตั้งค่ากฎการสนับสนุน , คลิก ตกลง .
  2. บน รหัสสินค้า โต้ตอบ ป้อนของคุณ รหัสสินค้า และคลิก ต่อไป .
  3. บน เงื่อนไขใบอนุญาต โต้ตอบ ยอมรับ ข้อตกลง และคลิก ต่อไป .
  4. บน อัพเดทสินค้า โต้ตอบ คลิก ต่อไป .
  5. บน ตั้งค่าไฟล์สนับสนุน โต้ตอบ คลิก ติดตั้ง .
  6. บน ตั้งค่ากฎการสนับสนุน โต้ตอบ คุณจะได้รับคำเตือน คลิก ต่อไป ละเว้นข้อความนี้ เนื่องจากเป็นที่คาดหมายในคลัสเตอร์การจัดเก็บข้อมูลแบบหลายไซต์หรือแบบไม่แบ่งใช้
  7. ตรวจสอบ การกำหนดค่าโหนดคลัสเตอร์ และคลิก ต่อไป .
  8. กำหนดค่า .ของคุณ เครือข่ายคลัสเตอร์ โดยเพิ่มที่อยู่ IP รอง “ที่สาม” สำหรับอินสแตนซ์ SQL ของคุณและคลิก ต่อไป . คลิก ใช่ เพื่อดำเนินการกำหนดค่าหลายซับเน็ต
  9. เข้า รหัสผ่าน สำหรับบัญชีบริการและคลิก ต่อไป .
  10. บน การรายงานข้อผิดพลาด โต้ตอบ คลิก ต่อไป .
  11. บน เพิ่มกฎโหนด ไดอะล็อก คำเตือนการทำงานที่ข้ามไปสามารถละเว้นได้ คลิก ต่อไป .
  12. ตรวจสอบคุณสมบัติและคลิก ติดตั้ง .
  13. คลิก ปิด I เพื่อสิ้นสุดขั้นตอนการติดตั้ง

การกำหนดค่าคลัสเตอร์ทั่วไป ส่วนนี้อธิบาย a การกำหนดค่าคลัสเตอร์ที่จำลองแบบ 2 โหนดทั่วไป .

  1. การกำหนดค่าเริ่มต้นต้องทำจาก DataKeeper UI ทำงานบนโหนดคลัสเตอร์ใดโหนดหนึ่ง หากไม่สามารถเรียกใช้ DataKeeper UI บนโหนดคลัสเตอร์ได้ เช่น เมื่อเรียกใช้ DataKeeper บนเซิร์ฟเวอร์ Windows Core เท่านั้น ให้ติดตั้ง DataKeeper UI บนคอมพิวเตอร์ทุกเครื่องที่ใช้ Windows XP หรือสูงกว่า และปฏิบัติตามคำแนะนำใน หลักเท่านั้น ส่วนสำหรับการสร้างมิเรอร์และการลงทะเบียนทรัพยากรคลัสเตอร์ผ่านบรรทัดคำสั่ง
  2. เมื่อ DataKeeper UI ทำงาน เชื่อมต่อกับแต่ละโหนด ในคลัสเตอร์
  3. สร้างงาน โดยใช้ DataKeeper UI กระบวนการนี้สร้างมิเรอร์และเพิ่มทรัพยากร DataKeeper Volume ไปยังที่เก็บข้อมูลที่มีอยู่

! สำคัญ: ทำให้เเน่นอน ชื่อเครือข่ายเสมือน สำหรับ การเชื่อมต่อ NIC เหมือนกันในโหนดคลัสเตอร์ทั้งหมด

  1. หากต้องการกระจกเพิ่มเติม คุณสามารถ เพิ่มกระจกเงาให้กับงาน .
  2. กับ ปริมาณ DataKeeper ตอนนี้ใน พื้นที่เก็บข้อมูลที่มีอยู่ คุณสามารถสร้างทรัพยากรคลัสเตอร์ (SQL, File Server เป็นต้น) ได้ในลักษณะเดียวกับที่มีทรัพยากรดิสก์ที่ใช้ร่วมกันในคลัสเตอร์ โปรดดูเอกสารประกอบของ Microsoft สำหรับข้อมูลเพิ่มเติมนอกเหนือจากข้างต้นสำหรับคำแนะนำในการกำหนดค่าคลัสเตอร์ทีละขั้นตอน

การเชื่อมต่อกับคลัสเตอร์ (เสมือน) IPs นอกจาก IP หลักและ IP รองแล้ว คุณจะต้องกำหนดค่าที่อยู่ IP เสมือนใน Huawei Cloud เพื่อให้สามารถกำหนดเส้นทางไปยังโหนดที่ใช้งานอยู่ได้

  1. จาก รายการบริการ ดรอปดาวน์ เลือก เซิร์ฟเวอร์คลาวด์ยืดหยุ่น .
  2. คลิกที่อินสแตนซ์ SQL ที่คุณต้องการเพิ่มที่อยู่ IP เสมือนของคลัสเตอร์ (หนึ่งรายการสำหรับ MSDTC และอีกรายการสำหรับ SQL Failover Cluster)
  3. เลือก NIC > จัดการที่อยู่ IP เสมือน .
  4. คลิกที่ กำหนดที่อยู่ IP เสมือน และเลือก คู่มือ ป้อนที่อยู่ IP ที่อยู่ภายในช่วงซับเน็ตสำหรับอินสแตนซ์ (เช่น สำหรับ 15.0.1.25 ให้ป้อน 15.0.1.26) คลิก ตกลง .
  5. คลิกที่ มากกว่า ดรอปดาวน์บนแถวที่อยู่ IP แล้วเลือก ผูกกับเซิร์ฟเวอร์ ให้เลือกทั้งเซิร์ฟเวอร์ที่จะผูกที่อยู่ IP และการ์ด NIC
  6. ใช้ขั้นตอนที่ 4 และ 5 เดียวกันสำหรับ IP เสมือน MSDTC และ SQLFC
  7. คลิก ตกลง เพื่อบันทึกงานของคุณ

การจัดการ เมื่อไดรฟ์ข้อมูล DataKeeper ลงทะเบียนกับ Windows Server Failover Clustering แล้ว การจัดการทั้งหมดของไดรฟ์ข้อมูลนั้นจะทำผ่านอินเทอร์เฟซ Windows Server Failover Clustering ฟังก์ชันการจัดการทั้งหมดมีอยู่ใน DataKeeper . ตามปกติ จะถูกปิดการใช้งาน บนโวลุ่มใดๆ ที่อยู่ภายใต้การควบคุมคลัสเตอร์ ทรัพยากรคลัสเตอร์ DataKeeper Volume จะควบคุมทิศทางมิเรอร์แทน ดังนั้นเมื่อ DataKeeper Volume ออนไลน์บนโหนด โหนดนั้นจะกลายเป็นแหล่งที่มาของมิเรอร์ คุณสมบัติของทรัพยากรคลัสเตอร์ DataKeeper Volume ยังแสดงข้อมูลการมิเรอร์พื้นฐาน เช่น แหล่งที่มา เป้าหมาย ประเภท และสถานะของมิเรอร์

การแก้ไขปัญหา ใช้แหล่งข้อมูลต่อไปนี้เพื่อช่วยแก้ไขปัญหา:

  • การแก้ไขปัญหา ส่วนปัญหา
  • สำหรับลูกค้าที่มีสัญญาการสนับสนุน – http://us.sios.com/support/overview/
  • สำหรับลูกค้าประเมินเท่านั้น – การสนับสนุนก่อนการขาย

แหล่งข้อมูลเพิ่มเติม: ทีละขั้นตอน: การกำหนดค่า 2-Node Multi-Site Cluster บน Windows Server 2008 R2 – ส่วนที่ 1 — http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-%E2%80%93 -ส่วนที่ 1/ ทีละขั้นตอน: การกำหนดค่า 2-Node Multi-Site Cluster บน Windows Server 2008 R2 – ตอนที่ 3 — http://clusteringformeremortals.com/2009/10/07/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-%E2%80%93 -ส่วน-3/

Filed Under: Datakeeper, ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์ Tagged With: SQL Server Failover Cluster

การเริ่มต้นที่ดีนั้นยอดเยี่ยม แต่การรักษาเวลาทำงานต้องใช้ความระมัดระวัง

กันยายน 28, 2021 by Jason Aw Leave a Comment

การเริ่มต้นที่ดีนั้นยอดเยี่ยม แต่การรักษาเวลาทำงานต้องใช้ความระมัดระวัง

การเริ่มต้นที่ดีนั้นยอดเยี่ยม แต่การรักษาเวลาทำงานต้องใช้ความระมัดระวัง

ผู้เขียน Isabella Poretsis กล่าวว่า “การเริ่มต้นบางสิ่งอาจเป็นเรื่องง่าย การทำให้สำเร็จซึ่งเป็นอุปสรรคสูงสุด” เป็นการดีที่จะมีการประชุมกำหนดการมันชุ่มชื่นและน่าตื่นเต้น ผู้จัดการและผู้นำมองออกไปที่กรีนฟิลด์ด้วยความตื่นเต้นและการมองโลกในแง่ดีอยู่ในระดับสูงแต่ช่วงเวลาเริ่มต้นนี้ และแม้แต่ช่วงเวลาที่แชมเปญเปิดตัวที่ประสบความสำเร็จก็เป็นเพียงจุดเริ่มต้นเท่านั้น การรักษาเวลาทำงานต้องใช้ความระมัดระวังอย่างต่อเนื่อง

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

สำหรับผู้ที่ต้องการตื่นตัวในการรักษาเวลาทำงาน ต่อไปนี้คือเคล็ดลับห้าประการ:

1. ตรวจสอบสิ่งแวดล้อม

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

2. ดำเนินการบำรุงรักษา

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

3. เรียนรู้อย่างต่อเนื่อง

การแนะนำความพร้อมใช้งานสูงครั้งแรกของฉันเกิดขึ้นเมื่อฉันถอดปลั๊ก Token Ring ด้านหนึ่งสำหรับเซิร์ฟเวอร์ในห้องแล็บของเราในฐานะผู้ฝึกงาน สดใหม่จากแล็บ CE-211ผู้ดูแลระบบจ้องหน้าฉันในไม่กี่นาทีหลังจากนั้นไม่นานเขาก็ให้การศึกษาแก่ฉันตามหลักการแล้ว คุณและทีมของคุณต้องการที่จะเรียนรู้โดยไม่ทำลายเครือข่ายของคุณ แต่คุณต้องการเรียนรู้ต่อไปอย่างแน่นอนดูหลักสูตรที่ต้องเสียค่าใช้จ่ายเกี่ยวกับเทคโนโลยีที่มีอยู่ รุ่นใหม่ โครงสร้างพื้นฐานที่เกิดขึ้นใหม่ตรวจสอบผู้จำหน่ายของคุณสำหรับหลักสูตรและรายการที่เกี่ยวข้องกับกระบวนการ สภาพแวดล้อม การปรับใช้ซอฟต์แวร์ และองค์กรของบริษัทหลักสูตรฟรีสำหรับหลายสิ่งหลายอย่างยังมีอยู่หากเงินเป็นปัญหา

4. ทวีคูณการเรียนรู้

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

5. จบด้วยดี . .before การเริ่มต้นครั้งต่อไป

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

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

-Cassius Rhue, VP, Customer Experience ทำซ้ำโดยได้รับอนุญาตจาก SIOS

Filed Under: ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์

ทำความเข้าใจและหลีกเลี่ยงสถานการณ์สมองแตก

กันยายน 23, 2021 by Jason Aw Leave a Comment

ทำความเข้าใจและหลีกเลี่ยงสถานการณ์สมองแตก

 

 

ทำความเข้าใจและหลีกเลี่ยงสถานการณ์สมองแตก

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

Failover Cluster Split Brain Scenario คืออะไร?

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

มีสถานการณ์สมมติสมองแตกสองประเภทซึ่งอาจเกิดขึ้นสำหรับลำดับชั้นทรัพยากร SAP HANA หากไม่มีการดำเนินการตามขั้นตอนที่เหมาะสมเพื่อหลีกเลี่ยง

  • HANA ทรัพยากรแยกสมอง: ทรัพยากร HANA ใช้งานอยู่ (ISP) บนโหนดคลัสเตอร์หลายโหนด สถานการณ์นี้มักเกิดจากการหยุดทำงานของเครือข่ายชั่วคราวที่ส่งผลต่อเส้นทางการสื่อสารระหว่างโหนดคลัสเตอร์
  • SAP HANA System Replication แยกสมอง: ทรัพยากร HANA ใช้งานอยู่ (ISP) บนโหนดหลักและสแตนด์บาย (OSU) บนโหนดสำรอง แต่ฐานข้อมูลกำลังทำงานและลงทะเบียนเป็นไซต์การจำลองแบบหลักบนทั้งสองโหนด สถานการณ์นี้มักเกิดจากความล้มเหลวในการหยุดฐานข้อมูลบนโหนดหลักก่อนหน้าระหว่างเกิดข้อผิดพลาด การเปิดใช้งาน Autostart สำหรับฐานข้อมูล หรือผู้ดูแลระบบฐานข้อมูลที่รัน “hdbnsutil -sr_takeover” ด้วยตนเองบนไซต์การจำลองแบบสำรองภายนอกสภาพแวดล้อมซอฟต์แวร์การทำคลัสเตอร์ .

หลีกเลี่ยงปัญหาสมองแตก

คำแนะนำในการหลีกเลี่ยงหรือแก้ไขสถานการณ์สมองแตกแต่ละประเภทใน ชุดป้องกัน SIOS สภาพแวดล้อมการจัดกลุ่มได้รับด้านล่าง

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

EMERG:hana:quickCheck:HANA-SPS_HDB00:136363:คำเตือน: เกิดความล้มเหลวในการสื่อสารชั่วคราวระหว่างเซิร์ฟเวอร์ hana2-1 และ hana2-2 จำเป็นต้องมีการแทรกแซงด้วยตนเองเพื่อลดความเสี่ยงของการสูญเสียข้อมูล 
เพื่อแก้ไขสถานการณ์นี้ โปรดยกเลิกการให้บริการลำดับชั้นทรัพยากรต่อไปนี้: HANA-SPS_HDB00 บน hana2-1 หรือ HANA-SPS_HDB00 บน hana2-2 
เซิร์ฟเวอร์ที่นำลำดับชั้นของทรัพยากรออกจากบริการจะกลายเป็นไซต์สำรอง SAP HANA System Replication

คำแนะนำสำหรับการแก้ปัญหา:

  1. ตรวจสอบฐานข้อมูลในแต่ละโหนดคลัสเตอร์เพื่อดูว่าอินสแตนซ์ใดมีข้อมูลล่าสุดหรือที่เกี่ยวข้องมากที่สุด การกำหนดนี้ต้องทำโดยผู้ดูแลระบบฐานข้อมูลที่มีคุณสมบัติซึ่งคุ้นเคยกับข้อมูล
  2. ทรัพยากร HANA บนโหนดที่มีข้อมูลที่จำเป็นต้องเก็บรักษาจะยังคงใช้งานอยู่ (ISP) ใน LifeKeeper และลำดับชั้นทรัพยากร HANA บนโหนดที่จะถูกลงทะเบียนใหม่เนื่องจากไซต์การจำลองแบบสำรองจะถูกนำออกจากบริการทั้งหมด ผู้ช่วยชีวิต. คลิกขวาที่ทรัพยากรลีฟแต่ละรายการในลำดับชั้นทรัพยากร HANA บนโหนดที่ควรนำลำดับชั้นออกจากบริการแล้วคลิก หยุดให้บริการ …
  3. เมื่อนำลำดับชั้นทรัพยากร SAP HANA ออกจากบริการเรียบร้อยแล้ว LifeKeeper จะลงทะเบียนโหนดสแตนด์บายอีกครั้งเป็นไซต์การจำลองแบบสำรองระหว่างช่วง quickCheck ถัดไป (ค่าเริ่มต้น 2 นาที) เมื่อการจำลองแบบกลับมาทำงานอีกครั้ง ข้อมูลใดๆ บนโหนดสแตนด์บายที่ไม่มีอยู่ในโหนดที่ใช้งานอยู่จะสูญหาย เมื่อโหนดสแตนด์บายได้รับการลงทะเบียนใหม่เป็นไซต์การจำลองแบบสำรอง ลำดับชั้น SAP HANA จะกลับสู่สถานะที่มีความพร้อมใช้งานสูง

SAP HANA System Replication แยกความละเอียดของสมอง

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

EMERG:hana:quickCheck:HANA-SPS_HDB00:136364:คำเตือน: ฐานข้อมูล SAP HANA HDB00 กำลังทำงานและลงทะเบียนเป็นต้นแบบหลักบนทั้ง hana2-1 และ hana2-2 จำเป็นต้องมีการแทรกแซงด้วยตนเองเพื่อลดความเสี่ยงของการสูญเสียข้อมูล เพื่อแก้ไขสถานการณ์นี้ โปรดหยุดอินสแตนซ์ฐานข้อมูล HDB00 บน hana2-2 โดยเรียกใช้คำสั่ง 'su – spsadm -c “sapcontrol -nr 00 -function Stop”' บนเซิร์ฟเวอร์นั้น เมื่อหยุดแล้ว จะกลายเป็นไซต์การจำลองข้อมูลระบบ SAP HANA สำรอง

คำแนะนำสำหรับการแก้ปัญหา:

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

    su – adm -c “sapcontrol -nr <Inst#> -function Stop” โดยที่ SAP System ID ตัวพิมพ์เล็กสำหรับการติดตั้ง HANA และ <Inst#> คือหมายเลขอินสแตนซ์สำหรับอินสแตนซ์ HDB (เช่น หมายเลขอินสแตนซ์ เช่น HDB00 คือ 00)

  3. เมื่อฐานข้อมูลหยุดทำงานสำเร็จแล้ว LifeKeeper จะลงทะเบียนโหนดสแตนด์บายอีกครั้งเป็นไซต์การจำลองแบบสำรองระหว่างช่วงเวลา quickCheck ถัดไป (ค่าเริ่มต้น 2 นาที) เมื่อการจำลองแบบกลับมาทำงานอีกครั้ง ข้อมูลใดๆ บนโหนดสแตนด์บายที่ไม่มีอยู่ในโหนดที่ใช้งานอยู่จะสูญหาย เมื่อโหนดสแตนด์บายได้รับการลงทะเบียนใหม่เป็นไซต์การจำลองแบบสำรอง ลำดับชั้น SAP HANA จะกลับสู่สถานะที่มีความพร้อมใช้งานสูง

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

 

 

ทำซ้ำโดยได้รับอนุญาตจาก SIOS

Filed Under: ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์ Tagged With: ลินุกซ์

สถาปัตยกรรมความพร้อมใช้งานสูงและแนวทางปฏิบัติที่ดีที่สุด

กันยายน 16, 2021 by Jason Aw Leave a Comment

สถาปัตยกรรมความพร้อมใช้งานสูงและแนวทางปฏิบัติที่ดีที่สุด

 

 

สถาปัตยกรรมความพร้อมใช้งานสูงและแนวทางปฏิบัติที่ดีที่สุด

13 ข้อเท็จจริงที่ไม่ค่อยมีใครรู้จักเกี่ยวกับความพร้อมใช้งานสูง

1. Hypervisor HA ไม่เหมือนกับ Application HA

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

2. ในความพร้อมใช้งานสูง ใหญ่ขึ้นไม่เท่ากับดีกว่า

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

3. ทุกอย่างล้มเหลว… บางครั้ง

ภาษาการเขียนโปรแกรมแอปพลิเคชันมีขึ้นในทศวรรษ 1950 และในขณะที่ภาษา โปรเซสเซอร์ IDE และคุณภาพของโค้ดได้รับการปรับปรุง ความจริงก็คือ “แอปพลิเคชันทั้งหมดล้มเหลวในบางจุด” ความล้มเหลวอันเนื่องมาจากข้อยกเว้น ข้อบกพร่อง การยุติที่ไม่สามารถจัดการได้ การยุติโดยไม่ได้ตั้งใจ การหมดทรัพยากร และอื่นๆ เกิดขึ้น ยังคงจำเป็นต้องมีกลยุทธ์ความพร้อมใช้งานของแอปพลิเคชันแบบแอ็คทีฟ/แอ็คทีฟ หรือแอ็คทีฟ/พาสซีฟ

4. มุ่งเน้นที่ ‘ทำไม’ มากเท่ากับ ‘อย่างไร’

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

  • ความล้มเหลว
  • ใช้จ่ายเกินตัว
  • ประสิทธิภาพต่ำ
  • ความสับสนและเหนือสถาปัตยกรรม
  • จากทั้งหมดที่กล่าวมา

แทนที่จะมุ่งเน้นไปที่การทำให้พร้อมใช้งาน ให้ใช้ทรัพยากรและความพยายามที่จำเป็นเพื่อทำความเข้าใจความต้องการทางธุรกิจและคำตอบสำหรับ “ทำไม”

5. ปัญหาที่ไม่ได้รับการแก้ไขมักเป็นที่มาของความเสียใจ

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

6. ปัญหาที่ไม่มีเอกสารทำให้เกิดการหยุดทำงานเช่นกัน

นึกภาพฉาก. ผู้ดูแลระบบคนใหม่กำลังมองหาเซิร์ฟเวอร์บนเครือข่าย รายงานการใช้งานระบุว่าเซิร์ฟเวอร์ไม่ทำงานและไม่มีการเชื่อมต่อไคลเอ็นต์ ไม่รู้จักเซิร์ฟเวอร์และไม่พบ “แท็ก” เอกสารประกอบหรือตัวระบุอื่น ๆ ผู้ดูแลระบบคนใหม่เชื่อว่าควรปิดตัวลง น่าเสียดายที่อินสแตนซ์ที่ไม่มีเอกสารและไม่ได้สื่อสารจริง ๆ แล้วเป็นเซิร์ฟเวอร์สำรองซึ่งการลบออกจะทำให้หยุดทำงานเมื่อหลักขัดข้องโดยไม่คาดคิด นี่ไม่ใช่เรื่องราวสมมติ แต่เป็นเรื่องจริงของผู้ดูแลระบบคนใหม่ซึ่งระบุเซิร์ฟเวอร์ว่าระบบ idle QA ไม่ได้ใช้งานอย่างไม่ถูกต้อง และปิดตัวลงก่อนการฝึกแพตช์

7. ความพอใจยังเป็นศัตรู

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

8. การเปลี่ยนแปลงเป็นเรื่องยาก

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

9. การเปลี่ยนแปลงทั้งหมดไม่ใช่การเปลี่ยนแปลงที่ดี

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

10. ถูกกว่าไม่ได้ดีกว่าเสมอไป

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

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

11. เสียงดังไม่เท่ากับผล

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

12. ความพร้อมใช้งานสูงเป็นวัฒนธรรมและความคิด ไม่ใช่แค่ผลิตภัณฑ์หรือโซลูชันฮาร์ดแวร์เท่านั้น

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

13. ตอนนี้ยังไม่สายเกินไป

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

ติดต่อ SIOS เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับ โซลูชันความพร้อมใช้งานสูง สำหรับการสมัครของคุณ

– Cassius Rhue, VP, ประสบการณ์ลูกค้าทำซ้ำจาก SIOS

Filed Under: ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์

12 คำถามเพื่อทำให้การย้ายระบบคลาวด์ของคุณไม่ซับซ้อน

กันยายน 10, 2021 by Jason Aw Leave a Comment

12 คำถามเพื่อทำให้การย้ายระบบคลาวด์ของคุณไม่ซับซ้อน

12 คำถามเพื่อทำให้การย้ายระบบคลาวด์ของคุณไม่ซับซ้อน

แนวทางปฏิบัติที่ดีที่สุดในการย้ายระบบคลาวด์

“ระบบคลาวด์มีความซับซ้อนมากขึ้น” เป็นคำกล่าวแรกในการสัมมนาผ่านเว็บความยาวชั่วโมงหนึ่งซึ่งมีรายละเอียดเกี่ยวกับการเปลี่ยนแปลงและโอกาสต่างๆ กับการเติบโตอย่างรวดเร็วของการประมวลผลแบบคลาวด์และการโยกย้ายระบบคลาวด์พรีเซนเตอร์กล่าวต่อด้วยโครงร่างของสิ่งที่เกี่ยวข้องกับระบบคลาวด์ซึ่งไอทีแบบเดิมกำลังเผชิญอยู่ในเส้นทางสู่ AWS , Azure , GCP หรือผู้ให้บริการอื่นๆ

มีเก้าส่วนที่ปรากฏเป็นความยุ่งยากในการเปลี่ยนผ่านไปสู่คลาวด์แบบเดิม:

  • คำจำกัดความ
  • ราคา
  • ระบบเครือข่าย
  • ความปลอดภัย
  • ผู้ใช้ บทบาท และโปรไฟล์
  • แอปพลิเคชันและใบอนุญาต
  • บริการและการสนับสนุน
  • ความพร้อมใช้งาน
  • สำรองข้อมูล

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

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

  1. เป้าหมายของเราในการย้ายไปยังคลาวด์คืออะไร
  2. สถาปัตยกรรมภายในองค์กรของคุณในปัจจุบันเป็นอย่างไร?คุณมีเอกสาร รายการ ผังงาน หรือตำราอาหารหรือไม่?
  3. แอปพลิเคชัน ฐานข้อมูล ความพร้อมใช้งาน และผู้ขายที่เกี่ยวข้องทั้งหมดของคุณได้รับการสนับสนุนบนแพลตฟอร์มผู้ให้บริการคลาวด์เป้าหมายของคุณหรือไม่
  4. ความเสี่ยงและข้อจำกัดในสถานที่ปัจจุบันของคุณคืออะไรแอปพลิเคชันใดบ้างที่ไม่มีการป้องกัน ปัญหาที่พบบ่อยที่สุดในองค์กรคืออะไร
  5. ใครเป็นผู้รับผิดชอบสถาปัตยกรรมและการออกแบบระบบคลาวด์?สถาปัตยกรรมและการออกแบบนี้จะอธิบายถึงคำจำกัดความปัจจุบันของคุณและคำจำกัดความของผู้ให้บริการระบบคลาวด์อย่างไร
  6. ผู้มีส่วนได้ส่วนเสียหลักคือใคร และอะไรคือเหตุการณ์สำคัญ ตัวขับเคลื่อนธุรกิจ และกำหนดเวลาสำหรับโครงการธุรกิจ
  7. คุณได้แบ่งปันแผนโครงการและเหตุการณ์สำคัญกับผู้ขายของคุณหรือไม่?
  8. กระบวนการในปัจจุบัน การกำกับดูแล และข้อกำหนดทางธุรกิจคืออะไร?
  9. งบประมาณการย้ายถิ่นคืออะไรและรวมถึงการเสริมพนักงาน การฝึกอบรม และบริการหรือไม่? ค่าบำรุงรักษา ใบอนุญาต และค่าใช้จ่ายในการดำเนินงานอย่างต่อเนื่องของคุณเป็นค่าประมาณเท่าใด
  10. ทักษะและความรับผิดชอบที่มีอยู่ในทีมของคุณมีอะไรบ้าง?
  11. ใครจะเป็นผู้รับผิดชอบในการอัปเดตการกำกับดูแล กระบวนการ โมเดลคลาวด์ใหม่ และบทบาทและความรับผิดชอบแบบดั้งเดิมต่างๆ
  12. แอปพลิเคชัน บริการ หรือฟังก์ชันใดบ้างที่จะย้ายจากรุ่น IaaS เป็น SaaS

รู้เป้าหมายของคุณสำหรับคลาวด์

ดังนั้น การตอบคำถามทั้งสิบสองข้อนี้จะปรับปรุงการโยกย้ายระบบคลาวด์ของคุณได้อย่างไร ดังที่คุณเห็นจากคำถาม การทำความเข้าใจเป้าหมายของคุณสำหรับระบบคลาวด์เป็นขั้นตอนแรกและสำคัญที่สุดเป็นที่ยอมรับกันในระดับสากลว่า “ผู้ให้บริการระบบคลาวด์ เช่น AWS, Azure หรือ Google สามารถจัดหาเซิร์ฟเวอร์ ที่เก็บข้อมูล และทรัพยากรการสื่อสารที่แอปพลิเคชันเฉพาะต้องการ” แต่สำหรับลูกค้าจำนวนมาก สิ่งนี้จะขจัด “เขาไม่จำเป็นต้องใช้คอมพิวเตอร์” ฮาร์ดแวร์และบุคลากรในการจัดการฮาร์ดแวร์นั้น” ด้วยเหตุนี้ ลูกค้าจึงมักให้ความสำคัญกับการรวมหรือลดอุปกรณ์หรือศูนย์ข้อมูล โดยไม่พิจารณาว่ามีโอกาสและช่องว่างเพิ่มเติมของระบบคลาวด์ที่พวกเขายังต้องพิจารณา ตัวอย่างเช่น cloud ทำ ขจัดการจัดการฮาร์ดแวร์ แต่มัน “ ไม่ ขจัดความต้องการทั้งหมดที่แอปพลิเคชันและการพึ่งพาจะมีสำหรับการตรวจสอบและการกู้คืน” ดังนั้นหากเป้าหมายของคุณคือการได้รับความพร้อมใช้งานทั้งหมดจากคลาวด์ คุณอาจไม่บรรลุเป้าหมายนั้น หรืออาจต้องการมากกว่าแค่การย้ายภายในองค์กร โมเดล IaaSการรู้เป้าหมายของคุณจะช่วยกำหนดเส้นทางของระบบคลาวด์ได้อย่างมาก

รู้จักสถาปัตยกรรมภายในองค์กรของคุณในปัจจุบัน

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

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

ทำความเข้าใจการเปลี่ยนแปลงทางธุรกิจและการกำกับดูแล

คำถามกลุ่มสุดท้ายช่วยให้ทีมของคุณเข้าใจกำหนดการ ผลกระทบทางธุรกิจ วันครบกำหนด และการเปลี่ยนแปลงการกำกับดูแลที่จำเป็นต้องอัปเดตหรือเปลี่ยน เนื่องจากอาจใช้ไม่ได้ในระบบคลาวด์อีกต่อไป การย้ายไปยังระบบคลาวด์อาจเป็นการเปลี่ยนแปลงและการเดินทางที่ราบรื่นอย่างไรก็ตาม ความล้มเหลวในการประเมินตำแหน่งของคุณในการเดินทางและเมื่อคุณจำเป็นต้องเดินทางให้เสร็จสิ้นอาจทำให้กลายเป็นฝันร้ายได้ การทำความเข้าใจเกี่ยวกับจังหวะเวลามีความสำคัญและสามารถช่วยได้อย่างมากโดยการพิจารณาผู้มีส่วนได้ส่วนเสีย ผู้จำหน่ายแอปพลิเคชัน เหตุการณ์สำคัญทางธุรกิจ และฤดูกาลของธุรกิจSIOS Technology Corp. ต้องการให้ลูกค้าเข้าใจเหตุการณ์สำคัญของตนอย่างเห็นแก่ตัว เพราะในฐานะผู้ให้บริการ จะลดความประหลาดใจให้เหลือน้อยที่สุด แต่เรายังสนับสนุนให้ลูกค้าตอบคำถามเหล่านี้ เนื่องจากพวกเขามักจะเปิดเผยความไม่สอดคล้องระหว่างแผนกและผู้มีส่วนได้ส่วนเสีย DBAs เชื่อว่าการตัดยอดจะเกิดขึ้นในสุดสัปดาห์สุดท้ายของเดือน แต่ Finance ตั้งใจที่จะปิดบัญชีในช่วงสุดสัปดาห์สุดท้ายของเดือนเดียวกัน หรือทีมไอทีเชื่อว่าการตัดยอดอาจเกิดขึ้นได้ในวันจันทร์ แต่ทีมแอปพลิเคชันไม่สามารถใช้งานได้จนถึงวันพุธ และบางทีที่สำคัญที่สุดทีมกฎหมายยังไม่ได้ตรวจสอบรายการ NDA ใหม่ ข้อตกลง ใบอนุญาต และการเปลี่ยนแปลงการกำกับดูแลที่จำเป็นในการดึง ทั้งหมดเข้าด้วยกัน

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

หากต้องการความช่วยเหลือเกี่ยวกับกลยุทธ์การย้ายระบบคลาวด์และการใช้งานที่มีความพร้อมใช้งานสูง โปรดติดต่อ SIOS Technology Corp. – Cassius Rhue, VP, Customer Experience เรียนรู้เพิ่มเติมเกี่ยวกับเรื่องทั่วไป ความท้าทายในการโยกย้ายระบบคลาวด์ .

อ่านเกี่ยวกับความเข้าใจผิดบางประการเกี่ยวกับ ความพร้อมใช้งานในระบบคลาวด์

สืบพันธุ์จาก SIOS

Filed Under: ทำให้เข้าใจง่ายเซิร์ฟเวอร์คลัสเตอร์

  • 1
  • 2
  • Next Page »

โพสต์ล่าสุด

  • 10 ข้อควรพิจารณาในการเลือกโซลูชันความพร้อมใช้งานสูงในสภาพแวดล้อม Nutanix
  • เซิร์ฟเวอร์ของฉันเป็นแบบใช้แล้วทิ้งหรือไม่? ซอฟต์แวร์ความพร้อมใช้งานสูงสอดคล้องกับแนวทางปฏิบัติที่ดีที่สุดของคลาวด์อย่างไร
  • กลยุทธ์การกู้คืนข้อมูลสำหรับโลกที่เสี่ยงต่อภัยพิบัติ
  • DataKeeper และเบสบอล: กลยุทธ์ในการกู้คืนจากภัยพิบัติ
  • การจัดทำงบประมาณสำหรับความเสี่ยงจากการหยุดทำงานของ SQL Server

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

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

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