โซลูชัน Database Mirroring ช่วยสร้างระบบจัดการฐานข้อมูลที่พร้อมใช้งานสูง (High Availability) ใน SQL Server ซึ่งค่อนข้างง่าย และเหมาะสำหรับฐานข้อมูลขนาดกลางและระดับต่ำกว่า
ข้อกำหนดของระบบจัดการฐานข้อมูลที่พร้อมใช้งานสูง กำลังด่วนขึ้นเรื่อยๆ บางครั้งเป็นปัจจัยชีวิตสำหรับองค์กรและบริษัท อย่างไรก็ตาม เพื่อให้บรรลุความพร้อมใช้งานสูง (เกือบทำงานตลอดเวลา) ไม่ใช่เรื่องง่าย เพราะมีปัจจัยหลายอย่างส่งผลต่อประสิทธิภาพระบบ: ปัญหาฮาร์ดแวร์ โครงสร้างพื้นฐานเครือข่าย ข้อผิดพลาดระบบปฏิบัติการ ข้อผิดพลาดซอฟต์แวร์แอปพลิเคชัน ไวรัส บทความแนะนำโซลูชันช่วยบรรลุความพร้อมใช้งานสูง (HA - High Availability) บนระบบจัดการฐานข้อมูลที่ใช้อยู่: SQL Server
โซลูชัน HA บน SQL Server
Failover Cluster
โซลูชันนี้ใช้ฮาร์ดดิสก์ร่วมกัน - ปกติคือ SAN เพื่อเก็บฐานข้อมูล มีหลาย ' instances ' ของ SQL Server ติดตั้ง แต่ละอินสแตนซ์เป็นโหนด (node) แต่ในเวลาเดียวกันมีเพียงโหนดเดียวที่ควบคุมฐานข้อมูล เมื่อโหนดนี้มีปัญหา อีกโหนดจะแทนที่จัดการฐานข้อมูล
Log Shipping
โครงสร้างเพิ่มเติมของฐานข้อมูลเป็น mirror (สำเนา) เมื่อมีการเปลี่ยนแปลงหรืออัปเดตจากฐานข้อมูลหลัก ไฟล์ล็อกที่บันทึกการเปลี่ยนแปลงเหล่านี้จะถูกส่งไปยังอินสแตนซ์เซิร์ฟเวอร์ mirror ด้วยวิธีนี้ สำเนาฐานข้อมูลที่อัปเดตแล้วจะได้รับการรักษา ในกรณีเกิดเหตุการณ์ ฐานข้อมูลสำเนาจะถูกแปลงเป็นฐานข้อมูลหลักในเวลาสั้น
รูปที่ 1 : การตั้งค่า SQL Server ให้พร้อมใช้งานตลอดเวลา
Replication
หาก Failover Cluster และ Log Shipping เป็นสองโซลูชันรับประกัน high-availability ระดับฐานข้อมูล Replication รับประกันความพร้อมใช้งานสูงเพียงระดับออบเจ็กต์ในฐานข้อมูล เช่น ตาราง, view ออบเจ็กต์เหล่านี้จะถูกคัดลอกไปยังอินสแตนซ์ที่ 2 ของ SQL Server เพื่อจัดเก็บ
Database Mirroring ใน SQL Server
Database Mirroring (DM) เป็นโซลูชันใหม่สำหรับสร้างฐานข้อมูลพร้อมใช้งานสูงใน SQL Server DM แก้ไขข้อเสียของโซลูชันก่อนหน้า เช่น:
• เทียบกับ Failover Cluster, DM ไม่ต้องการฮาร์ดแวร์พิเศษอย่าง SAN จึงลดต้นทุนการกำหนดค่า
• เทียบกับ Log Shipping, DM สลับไปยังเครื่อง mirror อัตโนมัติเมื่อเกิดข้อผิดพลาด โดยไม่ต้องการการกระทำของผู้ดูแลระบบ Log shipping ต้องกำหนดค่าด้วย T-SQL ด้วยตนเอง ดังนั้น DM เรียกว่า 'hot standby' เมื่อเวลาหยุดทำงาน (downtime) คำนวณเป็นวินาที และ Log-shipping เรียกว่า 'warm standby' เพราะเวลาหยุดทำงานอาจเป็นนาทีหรือมากกว่า
• เทียบกับ Replication DM เหนือกว่าเพราะปกป้องฐานข้อมูลทั้งหมด และ Replication ปกป้องเพียงส่วนของฐานข้อมูล เช่น ตาราง master
อย่างไรก็ตาม DM ใช้ได้เฉพาะในเวอร์ชัน Enterprise / Developer ของ SQL Server 2005 SP1 / 2008
1. โครงสร้าง DM ใน SQL Server
DM ใน SQL Server ต้องการ 3 อินสแตนซ์หลัก: 1 อินสแตนซ์ (บทบาท principal) จัดการฐานข้อมูล 1 อินสแตนซ์เพิ่มเติม (mirror) รับประกันสำเนาฐานข้อมูล อินสแตนซ์ของ witness เชื่อมต่อกับอินสแตนซ์หลักและรอง เพื่อตรวจสอบและรับประกันความพร้อมใช้งานของฐานข้อมูล
เมื่อมี witness server: เซิร์ฟเวอร์ witness เชื่อมต่อกับเซิร์ฟเวอร์หลักและ mirror ตอนนี้ระบบทั้งหมดกลายเป็น quorum ที่ 2 ใน 3 องค์ประกอบมีสิทธิ์ตัดสินใจ ในกรณีเซิร์ฟเวอร์หลักมีปัญหา เซิร์ฟเวอร์ witness จะสลับ mirror server เป็นเซิร์ฟเวอร์หลักโดยอัตโนมัติ หากหลังจากนั้น เซิร์ฟเวอร์หลักทำงานอีกครั้ง เซิร์ฟเวอร์หลักจะรับบทบาท mirror server (2 เซิร์ฟเวอร์สลับบทบาทกัน) จนกว่าจะมีการแทรกแซงของผู้ดูแลระบบ ( diagram 1 )
รูปที่ 2 : การตั้งค่า SQL Server ให้พร้อมใช้งานตลอดเวลา
เมื่อไม่มี witness server: กระบวนการสลับอัตโนมัติจะไม่ทำงานโดยไม่มีผลกระทบของผู้ดูแลระบบ
ใน SQL Server มีแนวคิด ' endPoint ' ที่ตีความได้ว่า 'จุดเชื่อมต่อ' อนุญาตให้อินสแตนซ์ SQL Server ติดต่อกันผ่าน TCP ( diagram 2 )
แต่ละ endpoint ระบุโดยที่อยู่และพอร์ตที่ตรงกัน ทฤษฎีที่ต้องเป็นที่อยู่โดเมนเต็ม แต่ในความเป็นจริง ใช้ได้ 4 วิธี:
- ระบุผ่านชื่อเซิร์ฟเวอร์ ตัวอย่าง: TCP: // PRINCIPAL: 7024
- ระบุผ่านชื่อโดเมน ตัวอย่าง: TCP: //PRINCIPAL.DELTAX.COM: 7024
- ระบุผ่าน IPv4 ตัวอย่าง: TCP: //192.168.1.3: 7024
- ระบุผ่าน IPv6
หมายเหตุ: ในกรณี SQL Server Instance รันบนเครื่องเดียวกัน พอร์ต TCP ต้องต่างกัน
2. การแลกเปลี่ยนข้อมูลระหว่างเซิร์ฟเวอร์หลักและรอง
รูปที่ 3 : การตั้งค่า SQL Server ให้พร้อมใช้งานตลอดเวลา
โหมดความเร็วสูง (High-Performance):
High-Performance mode ตรงกับการสร้างสำเนาแบบ asynchronous เซิร์ฟเวอร์หลักส่งอัปเดตไปยัง mirror server และดำเนินการเปลี่ยนแปลงอื่นๆ ต่อไป โดยไม่ต้องรอ mirror server อัปเดตสำเร็จ
โดยไม่รอ mirror server อัปเดตการเปลี่ยนแปลง เซิร์ฟเวอร์หลักมีความเร็วเข้าถึงเร็วกว่า และหลีกเลี่ยงการโหลดที่ไม่จำเป็น
กระบวนการนี้สามารถอธิบายได้โดยโครงร่างต่อไปนี้:
สำหรับโหมดความเร็วสูง mirror server อัปเดตช้ากว่าเซิร์ฟเวอร์หลักเสมอ และอาจเกิดการสูญเสียข้อมูล หากเซิร์ฟเวอร์หลักหยุดทำงานโดยไม่ส่งข้อมูลไปยัง mirror server ทัน แต่ส่วนฐานข้อมูลที่ต่างกันนี้ค่อนข้างเล็กและยอมรับได้ โหมดประสิทธิภาพสูง - High performance mode ไม่จำเป็นต้องมี Witness server
โหมดความปลอดภัยสูง (High-Safety):
ต่างจากโหมดความเร็วสูง โหมดความปลอดภัยสูงใช้กลไก Synchronous เมื่อแอปพลิเคชันหรือผู้ใช้อัปเดต จะถูกอัปเดตเกือบพร้อมกันบนเซิร์ฟเวอร์หลักและ mirror server นี่จะรับรองว่าเมื่อเซิร์ฟเวอร์หลักมีปัญหา mirror server จะมีสำเนาฐานข้อมูลสมบูรณ์และครบถ้วน ดังนั้นจึงรับประกันความปลอดภัยข้อมูลสูง
โหมดความปลอดภัยสูง ต้องการ witness server เพื่อรับประกัน hot standby - hot standby
3. การกำหนดค่า DM:
การกำหนดค่า DM บน SQL Server ประกอบด้วย 3 ขั้นตอนพื้นฐาน:
- สำรอง (backup) ฐานข้อมูลทั้งหมดบนเซิร์ฟเวอร์หลัก แล้วกู้คืน (restore) บน mirror server
- สร้าง endpoints ที่ตรงกัน เพื่อให้เซิร์ฟเวอร์หลัก mirror และ witness ทำงานร่วมกัน
- สร้างเซสชัน (Database Mirroring Session)
รูปที่ 4 : การตั้งค่า SQL Server ให้พร้อมใช้งานตลอดเวลา
การกำหนดค่า DM สามารถทำได้ผ่านอินเทอร์เฟซของ SQL Server Management Studio (SSMS) หรือกำหนดค่าด้วย T-SQL
การกำหนดค่าผ่านอินเทอร์เฟซ SSMS ค่อนข้างง่าย หลังจากกู้คืนข้อมูลบน mirror server สำเร็จ แค่คลิกขวาที่ฐานข้อมูล และเลือก ' Mirroring ' แล้วปฏิบัติตามขั้นตอน
ผลลัพธ์จะเป็นการเริ่มต้นเซสชัน DM
การกำหนดค่า SSMS อนุญาตให้ลบการดำเนินการส่วนใหญ่เมื่อทำด้วย T-SQL แต่หากต้องการ ยังคงสามารถใช้ T-SQL เพื่อความยืดหยุ่นสูงสุด
การกำหนดค่าด้วย T-SQL สามารถใช้ 2 วิธียืนยันตัวตนระหว่าง endpoints: ยืนยันด้วย login หรือการรับรองด้วย certificate โค้ด T-SQL เต็มสำหรับการกำหนดค่า DM ค่อนข้างยาว จึงแนะนำเพียงขั้นตอนเฉพาะตัว
การกำหนดค่าด้วย Login
สมมติเราใช้บัญชี Windows เข้าสู่ SQL Server ในกรณีใช้บัญชี SQL Server วิธีเดียวกัน
CREATE LOGIN [PRICIPAL-SRVAdministrator]
FROM WINDOWS
GO
สร้าง endpoints:
CREATE ENDPOINT Partner
STATE = STARTED
AS TCP (LISTENER_PORT = 5022)
FOR DATABASE_MIRRORING (
AUTHENTICATION = WINDOWS NEGOTIATE,
ENCRYPTION = SUPPORTED,
ROLE = ALL)
GO
สังเกตว่าการสร้าง endpoint ด้วย ROLE = ALL ต้องทำบน principal และ mirror servers ทั้งคู่ บน witness server แทนที่ด้วย ROLE = WITNESS
รูปที่ 5 : การตั้งค่า SQL Server ให้พร้อมใช้งานตลอดเวลา
การกำหนดค่าด้วย Certificate:
แทนที่จะใช้บัญชี login ให้แต่ละ endpoint ระบุตัวตนกัน สามารถใช้โซลูชันทางเลือก สร้าง certificate - ใบรับรอง
- สร้าง master key encryption (จำเป็นสำหรับส่งออก certificate):
tạo người dùng key xác thực từ mật khẩu = 'abc123 !!';
- สร้าง certificate:
create certificate PRINCIPAL_cert
with subject = 'PRINCIPAL certificate',
start_date = '2007/11/01',
expiry_date = '2020/11/01';
รูปที่ 6 : การตั้งค่า SQL Server ให้พร้อมใช้งานตลอดเวลา - สร้าง endpoint ที่ตรงกับ certificate:
Create endpoint endpoint_mirroring state = started
as tcp (listener_port = 7024, listener_ip = all)
for database_mirroring (authentication = certificate PRINCIPAL_cert, encryption = disabled, role = all);
- ส่งออก certificate ไปไฟล์แยก:
Backup certificate PRINCIPAL_cert to file = 'c: PRINCIPAL_cert.cer';
ทำซ้ำบน mirror server และ witness สังเกตเปลี่ยน role = witness เมื่อจำเป็น หลังสร้าง Endpoints และส่งออก certificates บนทั้ง 3 อินสแตนซ์ กลับไปที่ principal server:
- สร้าง login สำหรับ mirror server:
create login MIRROR_login with PASSWORD = 'abc123 !!';
GO
- สร้าง user ตรงกับ Login นั้น
create user MIRROR_user from login MIRROR_login;
GO
- สร้าง certificate จากไฟล์ .cer ของเซิร์ฟเวอร์:
Create certificate MIRROR_cert
Authorization MIRROR_user
From file = 'c: MIRROR_cert.cer';
GO
- ให้สิทธิ์เชื่อมต่อ endpoint ให้ login ของ mirror server:
Grant CONNECT ON Endpoint :: endpoint_mirroring to [MIRROR_login];
GO
รูปที่ 7 : การตั้งค่า SQL Server ให้พร้อมใช้งานตลอดเวลา ทำซ้ำสำหรับ certificate ของ witness server เช่นกัน และบน mirror และ witness servers เพื่อให้คอมพิวเตอร์ 3 เครื่องระบุและยืนยันตัวตนกัน
หลังสร้าง endpoints แล้ว สามารถตรวจสอบได้ด้วยคิวรี่:
SELECT name, state_desc, role_desc
FROM sys.database_mirroring_endpoint
งานสุดท้ายคือ เริ่มเซสชันสำหรับ DM:
* บน principal server:
ALTER DATABASE AdventureWorks
SET PARTNER = 'TCP: //mirror-srv.deltax.com: 5022'
GO
* บน mirror server:
ALTER DATABASE AdventureWorks
SET PARTNER = 'TCP: //pricipal-srv.deltax.com: 5022'
GO
* บน principal server ตั้งค่า witness server:
ALTER DATABASE AdventureWorks
SET WITNESS = 'TCP: //witness-srv.deltax.com: 5022'
GO
หลังระบบทำงานแล้ว สามารถติดตามได้ด้วยเครื่องมือ Database Mirroring Monitor :
รูปที่ 8 : การตั้งค่า SQL Server ให้พร้อมใช้งานตลอดเวลา
4. มิドルแวร์การเขียนโปรแกรม:
การใช้ DM ถูกกล่าวว่าเกือบโปร่งใสสำหรับการเชื่อมต่อฐานข้อมูลจากด้าน middleware หากคุณใช้ไลบรารี ADO.NET เพียงแค่ปรับ ConnectionString เพิ่มฟิลด์ ' failover partner ' สำหรับ mirror server เช่น:
Data Source = pricipal.database.com; Failover Partner = mirror.database.com; Initial Catalog = AdventureWorks;
Integrated Security = True;
เพิ่มเติม ADO.NET สร้าง ' connection pool ' ที่อนุญาตให้แคชการเชื่อมต่อที่เริ่มต้นแล้ว ดังนั้นในกรณีปัญหาที่นำไปสู่การสลับเซิร์ฟเวอร์ คุณต้องดำเนินการเพิ่มเติมอย่างกระฉับชะลำ ลบแคชนี้
SqlConnection.ClearPool (conn);
จบบท
รูปที่ 9 : การตั้งค่า SQL Server ให้พร้อมใช้งานตลอดเวลา DM ใน SQL Server ค่อนข้างง่าย ง่ายต่อการกำหนดค่า ใช้งาน และติดตาม แต่ความสามารถค่อนข้างจำกัด เหมาะสำหรับฐานข้อมูลขนาดกลางและระดับต่ำกว่า และสำหรับฐานข้อมูลขนาดใหญ่ที่มีข้อกำหนดเข้มงวดเรื่องความต่อเนื่อง วิธีที่เสนอไม่ได้ตอบสนอง แต่ต้องการโซลูชันระบบปฏิบัติการโดยรวม ฮาร์ดแวร์ เครือข่าย
บทความหวังว่าช่วยให้คุณได้ภาพรวมวิธีสร้างระบบจัดการฐานข้อมูลพร้อมใช้งานสูงใน SQL Server
อ้างอิง: https://technet.microsoft.com/en-us/library/cc917680.aspx
โชคดี
คุณเพิ่งอ่านจบบทความ "การตั้งค่า SQL Server ให้พร้อมใช้งานตลอดเวลา" ที่แก้ไขโดยทีม TipsMake เราหวังว่าบทความนี้ให้เคล็ดลับเทคโนโลยีที่มีประโยชน์ คุณสามารถค้นหาบทความคล้ายกันได้ ขอบคุณที่อ่านและติดตามเราอย่างสม่ำเสมอ
