Disaster Recovery ใช้ SAN Storage ทำดี? หรือใช้ Software ทำดีกว่า?

หลังจากมีเหตุชุมนุมและความรุนแรงเกิดขึ้นในประเทศไทยหลายครั้ง แนวคิดการทำ Disaster Recovery เพื่อปกป้องข้อมูลสำคัญทางธุรกิจก็ได้กลายเป็นที่สนใจมากขึ้น หลายหน่วยงานมีโครงการที่จะทำ Disaster Recovery Site หรือ DR Site ก็มีมากมาย แต่โดยรวมที่นิยมก็หนีไม่พ้นสองตัวเลือกระหว่าง “การใช้ SAN Storage ทำ DR Site” กับ “การใช้ Software ช่วยทำ DR Site” รวมถึงตัวเลือกอื่นๆ ด้วย วันนี้เราจะมาเปรียบเทียบกันครับว่าแต่ละแบบมีข้อดีข้อเสียแตกต่างกันอย่างไร

การใช้ SAN Storage ทำ DR Site

ไอเดียรวมๆ ของการใช้ SAN Storage ทำ DR Site ก็คือการทำ Storage Replication ข้ามไซต์นั่นเองครับ โดยเราจะต้องทำการซื้อ SAN Storage ยี่ห้อเดียวกัน รุ่นเดียวกัน หรือเป็นรุ่นที่ทำงานร่วมกันได้ ไปวางไว้ทั้งที่ Data Center หลัก และ DR Site ของเรา แล้วซื้อ License ในการทำ Remote Replication เพื่อให้ Storage ทั้งสองชุดทำการ Synchronize ข้อมูลกันอย่างสม่ำเสมอ

การใช้ SAN Storage ทำ DR Site

ข้อดี

  • แนวคิดเข้าใจง่าย
  • ไม่ขึ้นกับระบบปฏิบัติการที่ใช้ ระบบไหนที่สามารถใช้งาน SAN Storage ได้อยู่แล้ว ก็สามารถทำ Replication ได้ทันที
  • ไม่ขึ้นกับ Application ที่ใช้ ระบบไหนที่สามารถใช้งาน SAN Storage ได้อยู่แล้ว ก็สามารถทำ Replication ได้ทันที
  • ไม่ขึ้นกับจำนวนของ Server ที่ใช้ (บางยี่ห้อ)

ข้อเสีย

  • ข้อมูลที่ทำการ Synchronize ไม่เห็น State การทำงานของซอฟต์แวร์ ทำให้ไม่รับประกันผลการกู้คืนว่าจะกู้คืนสำเร็จหรือไม่ ผู้กู้ข้อมูลต้องใช้ความรู้ค่อนข้างมาก
  • ในระบบที่ไม่เคยมีการใช้งาน SAN Storage มาก่อน ก็จำเป็นจะต้องมีการ Migrate ระบบทั้งหมดที่ต้องการขึ้นมาบน SAN Storage ให้เรียบร้อยก่อน อาจทำให้โครงการเป็นไปอย่างล่าช้า
  • ผู้ดูแลระบบต้องทำการแก้ไขค่าต่างๆ ในระบบเครือข่ายเอง เพื่อให้ผู้ใช้งานในระบบเครือข่ายเปลี่ยนไปใช้ DR Site
  • เป็นการบังคับว่าต้องใช้ SAN Storage จากผู้ผลิตรายเดิมเท่านั้น

การให้ Application ทำ DR Site ด้วยตัวเอง

Application บางประเภท โดยเฉพาะ Database มักจะมี Module สำหรับการสำรองข้อมูล และการทำ DR Site มาให้อยู่แล้ว ดังนั้นการใช้งาน Module ของซอฟต์แวร์นั้นๆ เลย ก็ถือเป็นอีกทางเลือกหนึ่งที่นิยมทำเช่นกัน

ข้อดี

  • การสำรองข้อมูลและกู้คืนเป็นไปได้ด้วยดี และง่าย รับประกันผล เนื่องจากผู้ผลิตซอฟต์แวร์และผู้ผลิต DR Module เป็นผู้ผลิตรายเดียวกัน ย่อมมีความเข้าใจใน Application ตัวเองสูง
  • สามารถใช้ DR Site เป็น Virtual Server ได้
  • ไม่ขึ้นกับ Hardware ที่ใช้

ข้อเสีย

  • ราคามักจะแพง เนื่องจาก Application ระดับที่มีการเขียน DR Module เอง ส่วนมากจะเป็น Application ที่ราคาแพงอยู่แล้ว อีกทั้งตัว DR Module เองก็ต้องมีความสเถียรมาก ต้องใช้ทีมงานเฉพาะในการพัฒนา ราคาจึงสูงขึ้นไปอีก
  • ถ้าเราต้องการทำ DR Site ให้กับระบบที่ไม่มี DR Module ของตัวเอง ทางเลือกนี้ไม่ใช่ทางเลือกที่เป็นไปได้
  • ผู้ดูแลระบบต้องทำการแก้ไขค่าต่างๆ ในระบบเครือข่ายเอง เพื่อให้ผู้ใช้งานในระบบเครือข่ายเปลี่ยนไปใช้ DR Site

การใช้ Software เฉพาะทางสำหรับการทำ DR Site

การใช้ Software เฉพาะทางทำ DR Site


ปัจจุบันมีผู้ผลิตหลายรายที่ทำ Software เฉพาะทางสำหรับการทำ DR Site ซึ่งถือว่าเป็นทางเลือกที่ค่อนข้างน่าสนใจในเวลานี้

ข้อดี

  • รองรับการทำ DR Site สำหรับระบบปฎิบัติการและ Application ที่หลากหลาย ทำให้สามารถใช้งานได้ง่าย ทั้งการสำรองข้อมูล และการกู้คืน
  • สามารถกำหนดค่า Configuration ได้หลากหลาย ไม่ว่าจะเป็นการกำหนด Schedule, การกำหนด Bandwidth หรือแม้แต่ลำดับในการ Boot ระบบต่างๆ ขึ้นมาที่ DR Site เมื่อเกิดเหตุฉุกเฉิน, เงื่อนไขในการนับว่า Service หยุดทำงาน รวมถึงเลือกระดับในการทำ DR ได้ (Backup/Recovery, Real Time High Availability)
  • มีตัวช่วยในการแก้ไขค่าต่างๆ ในระบบเครือข่าย เพื่อให้ผู้ใช้งานเข้าถึง DR Site ได้โดยอัตโนมัติ
  • ซอฟต์แวร์มีความน่าเชื่อถือสูง เนื่องจากผู้ผลิตระบบ DR Site โดยมาก จะเป็นผู้ผลิตซอฟต์แวร์ Backup/Recovery มาก่อน
  • สามารถใช้ DR Site เป็น Virtual Server ได้
  • ไม่ขึ้นกับ Hardware ที่ใช้

ข้อเสีย

  • ราคาสูงกว่าการใช้ SAN Storage ทำ DR Site แต่ยังถูกกว่าการใช้ DR Module เฉพาะของแต่ละ Application
  • บาง Application ที่ไม่มีระบุอยู่ในรายการ Application ที่สนับสนุน อาจต้องทำ PoC ก่อน
  • ขึ้นอยู่กับระบบปฎิบัติการที่สนับสนุน

การนำ Global Server Load Balancer มาใช้

Global Server Load Balance จริงๆ แล้วไม่ได้เป็นวิธีการในการสำรองข้อมูลแต่อย่างใด แต่เป็นตัวช่วยในการตรวจจับ Service Failure และ Activate DR Site ขึ้นมาโดยอัตโนมัติ ให้ผู้ใช้งานสามารถใช้งานระบบที่ DR Site ได้โดยไม่รู้สึกตัว และผู้ดูแลระบบไม่ต้องทำการแก้ไขค่าต่างๆ บนระบบเครือข่ายด้วยตัวเอง ดังนั้นในระบบก็ยังคงจำเป็นต้องมีวิธีการอื่นๆ ในการ Replicate ข้อมูลข้ามสาขาอยู่ดี

Global Load Balance

ส่วนวิธีการอื่นๆ นอกเหนือจากที่กล่าวมานี้ ก็ได้แก่การใช้งาน File System เฉพาะทาง หรือการนำเทคโนโลยี Virtualization มาช่วยทำ DR Site ซึ่งปัจจุบันยังไม่แพร่หลายนัก เพราะมีความซับซ้อนสูง และต้องลงทุน Infrastructure ค่อนข้างมาก ในขณะที่อีกแนวทางหนึ่งที่เมืองนอกเริ่มมีกัน คือการทำ DR Site บน Cloud Data Center ซึ่งก็จะมีหลักการไม่ต่างจากการใช้ Software ทำ DR Site นัก เพียงแต่ปลายทางใช้ Cloud Server แทน Physical Server เท่านั้น

อีกแนวคิดหนึ่งที่มีคนถามมากันค่อนข้างเยอะ คือจะทำอย่างไรให้ Data Center เป็นเหมือน Google ได้ คือมีกระจายอยู่ทั่วโลก และสำรองข้อมูลกันอยู่ทั่วโลก อันนี้ขอตอบคร่าวๆ ไว้ก่อนเลยว่า เพราะ Google ไม่ได้ใช้ระบบปฎิบัติการทั่วๆ ไปแบบที่เราใช้, ไม่ได้ใช้ Storage ทั่วๆ ไปแบบที่เราใช้, ไม่ได้ใช้ Software ทั่วๆ ไปแบบที่เราใช้ และไม่ได้เขียนโค้ดแบบทั่วๆ ไปอย่างที่เราใช้กันครับ ดังนั้นในตลาดของ Enterprise อย่างเรา ก็คงไม่อาจทำเหมือน Google ได้แบบเป๊ะๆ แต่ก็ยังมี ISP บางเจ้า ที่พยายามทำระบบที่มีการ DR ทั่วโลกให้เราใช้กันโดยง่ายที่สุด แต่แน่นอนครับ ราคาก็แพงเอาเรื่องเหมือนกันครับ 😀

สำหรับวันนี้ขอลาเพียงเท่านี้ครับ สวัสดีครับ

———-

บทความโดย Throughwave Thailand

ท่านสามารถติดตามข่าวสารเพิ่มเติมได้ที่ https://www.throughwave.co.th