ออกแบบ SQL Server AlwaysOn อย่างไรให้ไร้เทียมทาน Part 1
บังเอิญว่า…ในช่วงนี้เราเพิ่งได้อัปเดต SQL Server database on-premise จาก SQL Server 2017 และ Windows Server 2012 R2 ไป SQL Server 2019 บน Windows Server 2019 ซึ่งสำหรับเราเป็นเรื่องปกติในการคอย update Tech Stack ของเราให้ทันสมัยอยู่เสมอ แต่สิ่งที่แตกต่างออกไปในครั้งนี้ก็คือ เราตัดสินใจจะอัปเดต OS ด้วยใน Clustered Environment ครับ
วันนี้…ผมเลยถือโอกาสมาแชร์ครับว่า Architecture ที่เราใช้อยู่ปัจจุบันวางอย่างไร ? จริงๆ แล้ว..ถ้าจะให้แนะนำว่าส่วนไหนที่ควรจะเริ่มทำ HA (High Availability) ก่อน ผมขอแนะนำว่าควรจะเริ่มที่ส่วน Database Layer นั่นเองครับ เหตุผลส่วนหนึ่งคือเรื่องความสำคัญของข้อมูลด้วย แม้ว่าจะมี Backup process แล้ว แต่ก็ยังสู้แบบเสมือน real-time backup โดยใช้ High Availability ที่จะทำให้เราสามารถทำงานได้อย่างต่อเนื่องไม่ได้เลย และด้วย SQL Server ในเวอร์ชันปัจจุบันนั้น..บอกได้ว่าง่ายมากเลยครับ ! และดีมากด้วย :)
The Layout : ผังโครงสร้างใหญ่
สำหรับครั้งนี้…พิเศษสุดๆ ไปเลยครับ !! ผมจะขอแชร์ข้อมูลอย่างเต็มที่แบบว่าพนักงานใน Gofive เอง…คงเพิ่งจะรู้จากโพสนี้เหมือนกันครับว่า เมื่อ 5–6 ปีที่ผ่านมา เราวาง Architecture กันอย่างไร ? ไม่เพียงเพื่อ High Availability แต่เพื่อ Performance เช่นกันครับ โดยเราจะใช้ทั้งหมด 3 Servers ด้วยกัน
APOLLO คือชื่อ Database Server ของเราครับ เราจะใช้ชื่อ APOLLO เพื่อให้ง่ายในการเขียนโค้ด,ใช้งานและการติดต่อ แต่แน่นอน ! จริงๆแล้ว…เซิร์ฟเวอร์นี้ไม่ได้มีอยู่จริงครับ ถึงจะเป็น Virtual Server ก็จริงแต่จะรันแยกอยู่กันคนละ Physical นะครับ เบื้องหลังก็คือ APOLLO01 และ APOLLO02 โดยเราแบ่งออกเป็น 2 กลุ่ม กลุ่มแรกสำหรับงาน Database และกลุ่มที่ 2 คือสำหรับงาน Reporting Services (Report Server) โดยเฉพาะ หากบริษัทใดไม่ได้มีการใช้ SSRS แล้วนั้น ก็อาจจะไม่มีความจำเป็นต้องแยก Server มาก็ได้ครับ แต่ตรงนี้ที่เราแยกเพื่อ Optimize เรื่องของ Performance ให้ดียิ่งขึ้น ในส่วนของตัว Reporting Server นั้น เราก็ทำ DNS Redirection เช่นกัน เผื่อ Scale out ในอนาคตครับ
Disk Sizing Layout ก็สำคัญนะ
สำหรับ APOLLO01 และ APOLLO02 เราออกแบบ Disks เพิ่มเติมเพื่อ Performance ครับ โดยแบ่งออกเป็น 3 Disks ครับ จริงๆแล้ว…เราเลือกใช้ Virtual Server ทั้งหมดเพื่อความยืดหยุ่นในการ Scale-up หรือ upgrade hardware ในอนาคต รวมถึงหากมีความจำเป็นที่จะต้องขยายเพิ่มเนื้อที่ HDD เมื่อมีการใช้พื้นที่มากยิ่งขึ้นหรือหลายคนอาจไม่แน่ใจเรื่อง sizing วิธีนี้ก็จะช่วยลดความกังวลให้น้อยลง เพราะอย่างน้อยหากไม่พอก็ allocate เพิ่มได้ และการต้องลงทุนเผื่อในอนาคตทั้งหมดอีกด้วย ในความคิดเห็นส่วนตัวจากการใช้งานมามากกว่า 5 ปี มองว่าเป็นการตัดสินใจที่ใช่ ! เลยครับ
สำหรับ HDD นั้น ได้ออกแบบมาตั้งแต่ตอนซื้อเซิร์ฟเวอร์เลยครับ เพื่อให้แน่ใจว่า Physical Disks นั้นถูกแบ่งเป็น 3 กลุ่มเช่นกัน กลุ่มแรกคือ System OS กลุ่มที่ 2 คือ Data ไว้สำหรับเก็บตัว .mdf และกลุ่มที่ 3 คือ Log สำหรับเก็บ .ldf แต่สำหรับบางที่อาจจะมีมากกว่านี้คือแยกสำหรับเก็บ temp ด้วยก็ได้ครับ แต่สำหรับเรา ณ ตอนนั้นเราเลือกโฟกัสที่ 3 กลุ่มหลัก
ณ ตอนนั้น SSD เป็นอะไรที่ใหม่มากสำหรับวงการ Server และมีราคาสูงมาก แต่สุดท้าย…เราเลือกตัดสินใจที่จะลงทุน All Flash Storage มาใช้เป็นหลักสำหรับ Apollo โดยเฉพาะ ทั้งนี้แล้วแต่ความเหมาะสมและงบการลงทุนของแต่ละที่ด้วยครับ ณ ปัจจุบัน ราคาตอนนี้ก็ลงมาเยอะมากแล้ว ก็ถือว่าเป็นตัวเลือกที่น่าสนใจมากๆครับ ผมว่าเหมาะมากสำหรับใช้กับ Database คุ้มค่าครับ ! ถ้าพูดถึง Server Spec ที่ผมจะแนะนำให้ควรซื้อเผื่อไว้คือ RAM ด้วยนะครับ ผมชอบมากเลย ! RAM กับ Database ตอนนี้อย่าง APOLLO ก็ allocate ไปตัวละ 64GB สำหรับ Database Server ครับ ส่วน Reporting Server เรา allocate ไป 8GB ก็ดูเหมือนจะเพียงพอ (อย่าง..งงๆ)
อะไรอีกที่ควรรู้
สิ่งที่สำคัญคือ AlwaysOn หลัก ๆ ที่เราจะได้คือแค่ Sync Database นะครับ ส่วนที่เหลือ configuration ต่างๆ นั้นเราต้องทำเองในแต่ละ Server ยิ่งหากเราใช้ฟีเจอร์อื่นๆ เช่น Database Mail, SQL Agent ก็ต้องตั้งค่าให้ครบทุกเซิร์ฟเวอร์ด้วยครับ รวมถึง Logins และ Jobs ด้วย
สิ่งที่จะช่วยได้เวลาที่เราทำคือ มี Job สำหรับ Sync Logins โดยเฉพาะจาก APOLLO01 ตัวหลัก หรือตัว SSIS ก็ต้องตรวจสอบด้วยครับ เพราะว่าจะต้อง Enable AlwaysOn Support เพิ่มเติม
แนะนำเพิ่มเติมคือ เราควรทดสอบ Manual Failover เพื่อให้แน่ใจว่าระบบต่างๆทำงานปกติ โดยเฉพาะในส่วน Jobs, Logins, SSIS, Database Mail เป็นต้น สำหรับวิธีการ Sync Logins และ Jobs สามารถอ่านได้จากบทความนี้ก็ได้ครับ เมื่อก่อนผมเขียน SSIS Package ขึ้นมาเองเลยครับ แต่ตอนนี้จำไม่ได้แหละ !! สมัยนั้นยังไม่มี Tooling ดีๆ เยอะเหมือนสมัยนี้ด้วยครับ
เดี๋ยวนี้ ! อาจจะดีขึ้นแล้ว…จุดที่สำคัญเลยนะครับ แม้ว่าระบบจะตั้งเป็น Automatic Fail-over แต่เราไม่ควรอยู่ดี ๆ ไป Restart Primary Server เลยนะครับ
ถ้าหากเราต้องการ Restart หรือ Shutdown Primary Server เราควรเข้าไป Manual Fail-over ไปที่ตัว Secondary ก่อนเสมอครับ ไม่งั้นอาจจะมี Down-time gap เกิดขึ้นได้
2020 แล้วตอนนี้เป็นอย่างไร
จากเดิม…ที่เราเข้าใจว่าเรารันอยู่บนเวอร์ชันใหม่ล่าสุดในสมัยนั้นคือ Windows Server 2012 R2 แล้วก็เริ่มต้นจาก SQL Server 2014 จนเริ่มทยอยอัปเดตมาเป็น SQL Server 2017 ในเวลาต่อมา
เดี๋ยว Part 2 จะมาแชร์ประสบการณ์ที่เราเพิ่งอัปเดตทั้ง Windows และ SQL Server ไปเป็น 2019 ด้วยกันทั้งคู่ ผมบอกได้เลยว่าสนุกมากครับ จริงๆ แล้วมันคือเนื้อหาหลักที่ผมอยากจะมาแชร์ประสบการณ์ว่าเกิดอะไรขึ้นบ้าง การอัปเกรด OS ด้วย SQL Server ด้วยใน Clustered Environment มีความเสี่ยงมากแค่ไหน สามารถทำได้จริงหรือเปล่า และผลลัพธ์ที่ได้มาคืออะไร เอาไว้ผมจะมาแชร์ให้ฟังใน Part 2 นะครับ…ติดตามกันด้วยนะครับผม ^^
