การคำนวณความพร้อมใช้งานของแอปพลิเคชันในคลาวด์
เมื่อปรับใช้แอปพลิเคชันที่สำคัญทางธุรกิจในระบบคลาวด์คุณต้องแน่ใจว่าแอปพลิเคชันเหล่านี้พร้อมใช้งานสูง ข่าวดีก็คือหากคุณวางแผนอย่างถูกต้องคุณจะมีความพร้อมใช้งาน 99.99% (4-nines) หรือมากกว่านั้น อย่างไรก็ตามการคำนวณความพร้อมใช้งานที่แท้จริงของคุณอาจไม่ตรงไปตรงมาอย่างที่คิด
เมื่อพิจารณาถึงความพร้อมใช้งานคุณต้องพิจารณาองค์ประกอบหลักที่ทำให้การเข้าถึงแอปพลิเคชันของคุณเป็นไปได้ซึ่งฉันจะเรียกว่าโซ่ความพร้อมใช้งาน ส่วนประกอบของห่วงโซ่ความพร้อมใช้งาน ได้แก่ :
- คำนวณ
- เครือข่าย
- การจัดเก็บ
- ใบสมัคร
- บริการตามความต้องการ
แอปพลิเคชันของคุณจะพร้อมใช้งานเป็นลิงก์ที่อ่อนแอที่สุดเท่านั้นและการหยุดทำงานของคุณจะเพิ่มขึ้นเป็นทวีคูณด้วยลิงก์เพิ่มเติมแต่ละลิงก์ที่คุณเพิ่มลงในเครือข่ายลองตรวจสอบแต่ละลิงก์
ความพร้อมในการคำนวณ
ผู้ให้บริการคลาวด์รายใหญ่สามรายแต่ละรายมีความคล้ายคลึงกันบางประการ สิ่งหนึ่งที่เหมือนกันในทั้งสามแพลตฟอร์มคือข้อตกลงระดับบริการ (SLA) ที่พวกเขาจะยอมรับในการคำนวณ
SLA สำหรับผู้ให้บริการระบบคลาวด์สาธารณะทั้งสามสำหรับ VM เมื่อคุณมี VM สองรายการขึ้นไปที่กำหนดค่าในโซนความพร้อมใช้งานที่แตกต่างกันคือ 99.99%โปรดทราบว่า SLA นี้รับประกันเฉพาะการเข้าถึงระยะไกลของหนึ่งใน VMs ในช่วงเวลาใดเวลาหนึ่งโดยไม่มีสัญญาเกี่ยวกับความพร้อมใช้งานของบริการหรือแอปพลิเคชันที่ทำงานอยู่ภายใน VMหากคุณปรับใช้ VM เดียวภายในศูนย์ข้อมูลเดียว SLA นี้จะแตกต่างกันไปตั้งแต่“ 90% ของแต่ละชั่วโมง” (AWS) ถึง 99.5% (Azure และ GCP) หรือ 99.9% (Azure single VM เมื่อใช้ Premium SSD)
ความพร้อมใช้งานสูงอย่างแท้จริงเริ่มต้นที่ 99.99% ดังนั้นขั้นตอนแรกคือการตรวจสอบให้แน่ใจว่าแอปพลิเคชันของคุณพร้อมใช้งานคือตรวจสอบให้แน่ใจว่าแอปพลิเคชันได้รับการแจกจ่ายไปยัง VM สองเครื่องหรือมากกว่าซึ่งครอบคลุมโซนความพร้อม ด้วย VM สองตัวที่กระจายอยู่ในโซนความพร้อมใช้งานสองโซนทำให้คุณมี VM อย่างน้อยหนึ่งตัวที่พร้อมใช้งาน 99.99% คุณสามารถตั้งทฤษฎีได้ว่าหากคุณมี VM สามเครื่องที่กระจายอยู่ในโซนความพร้อมใช้งาน 3 โซนความพร้อมของคุณจะมากกว่า 99.99% แม้ว่า SLA ของผู้ให้บริการระบบคลาวด์จะไม่รับประกันความพร้อมใช้งานเกิน 99.99% โดยไม่คำนึงถึงจำนวนโซนความพร้อมใช้งานที่ใช้งาน แต่หากคุณใช้สถิติที่แท้จริงคุณอาจสรุปได้ว่าความพร้อมใช้งานของคุณอาจเพิ่มขึ้นสูงถึง 99.999999% หรือ 8-nines ของ ความพร้อมใช้งานการหยุดทำงาน 26.30 มิลลิวินาทีต่อเดือน
1 – (. 0001 * .0001) = .99999999
99.999999% พร้อม 3 โซนความพร้อม?
อย่าไปอ้างตัวเลขนั้น แต่อย่าลืมว่ามันสมเหตุสมผลแล้วถ้าโซนความพร้อม 2 โซนสามารถให้คุณพร้อมใช้งานได้ 99.99% เป็นไปตามเหตุผลว่าโซนความพร้อมใช้งาน 3 แห่งจะให้ความพร้อมใช้งานมากกว่า 99.99%
Compute เป็นเพียงลิงก์เดียวในห่วงโซ่ความพร้อมใช้งาน เรายังคงต้องจัดการกับเครือข่ายพื้นที่จัดเก็บข้อมูลและบริการอื่น ๆ ที่ต้องพึ่งพาซึ่งทั้งหมดนี้แสดงถึงจุดที่เป็นไปได้ของความล้มเหลว
ความพร้อมใช้งานของเครือข่าย
เพื่อให้แอปพลิเคชันของคุณพร้อมใช้งานเครือข่ายทุกเครือข่ายระหว่างไคลเอนต์และแอปพลิเคชันและทรัพยากรทั้งหมดที่แอปพลิเคชันขึ้นอยู่จะต้องพร้อมใช้งานและทำงานในช่วงเวลาแฝงที่ยอมรับได้ คุณต้องเข้าใจการเชื่อมโยงเครือข่ายระหว่างเซิร์ฟเวอร์ฐานข้อมูลแอ็พพลิเคชันเซิร์ฟเวอร์เว็บเซิร์ฟเวอร์และไคลเอ็นต์เพื่อให้ทราบอย่างแม่นยำว่าเครือข่ายอาจล้มเหลวที่ใด โปรดจำไว้ว่ายิ่งลิงก์ในห่วงโซ่ความพร้อมใช้งานของคุณมีความพร้อมใช้งานโดยรวมลดลง
แม้ว่าความพร้อมใช้งานของเครือข่ายระหว่าง VM ใน vNet เดียวกันจะครอบคลุมภายใต้ SLA การประมวลผลมาตรฐาน แต่ก็มีบริการเครือข่ายอื่น ๆ ที่คุณอาจใช้ นี่เป็นเพียงตัวอย่างบางส่วนของบริการเครือข่ายที่คุณสามารถใช้ได้ซึ่งจะส่งผลต่อความพร้อมใช้งานของแอปพลิเคชันโดยรวม
เส้นทางด่วน – 99.95%
เกตเวย์ VPN – 99.9% ถึง 99.95%
ตัวจัดสรรภาระงาน – 99.99%
ผู้จัดการจราจร – 99.99%
ตัวปรับสมดุลโหลด – 99.99%
เชื่อมต่อโดยตรง – 99.9% – 99.99%
จากสิ่งที่เราได้เรียนรู้ไปแล้วเรามาดูความพร้อมใช้งานของแอปพลิเคชันที่ใช้งานได้ในสองโซนความพร้อมใช้งาน
ความพร้อมในการประมวลผล 99.99%
ความพร้อมใช้งานของตัวจัดสรรภาระงาน 99.99%
.9999 * .9999 = .9998
ความพร้อมใช้งาน 99.98% = การหยุดทำงานประมาณ 9 นาทีต่อเดือน
ตอนนี้เราได้จัดการกับความพร้อมในการประมวลผลและเครือข่ายแล้วเรามาดูพื้นที่เก็บข้อมูลกัน
ความพร้อมในการจัดเก็บ
ตอนนี้ที่นี่เป็นที่ที่เรื่องราวมีขนเล็กน้อย ดู SLA หน่วยเก็บข้อมูลต่อไปนี้
https://azure.microsoft.com/en-us/support/legal/sla/storage/v1_5/
https://cloud.google.com/storage/sla
https://aws.amazon.com/compute/sla/
ดูเหมือนชัดเจนว่า Azure และ Google กำลังให้ SLA 99.9% สำหรับโซลูชันการจัดเก็บบล็อก AWS ไม่ได้กล่าวถึง EBS โดยเฉพาะที่นี่ พวกเขาพูดถึง VM และวัดความพร้อมใช้งาน VM ของอินสแตนซ์เดียวเป็นรายชั่วโมงแทนที่จะเป็นรายเดือนเหมือนที่ผู้ให้บริการคลาวด์รายอื่นทำ เพื่อประโยชน์ในการสนทนาให้ใช้การรับประกันความพร้อมใช้งาน 99.9% ที่ทั้ง Azure และ GCP ได้เผยแพร่
จากตัวอย่างก่อนหน้านี้เรามาเพิ่มพื้นที่เก็บข้อมูลให้กับสมการกัน
ความพร้อมในการประมวลผล 99.99%
ความพร้อมใช้งานของตัวจัดสรรภาระงาน 99.99%
ดิสก์ที่มีการจัดการ 99.9%
.9999 * .9999 * .999 = .9988
ความพร้อมใช้งาน 99.88% = ~ 53 นาทีของการหยุดทำงานต่อเดือน
การหยุดทำงาน 53 นาทีนั้นมากกว่าเวลาหยุดทำงาน 9 นาทีที่เราคำนวณไว้ในตัวอย่างก่อนหน้านี้มาก เราจะทำอย่างไรเพื่อลดผลกระทบจากความพร้อมใช้งานของพื้นที่จัดเก็บ 99.9% เราต้องสร้างความซ้ำซ้อนในการจัดเก็บมากขึ้น!
โชคดีที่เรามักจะรวมความซ้ำซ้อนของพื้นที่เก็บข้อมูลไว้ด้วยเมื่อวางแผนสำหรับความพร้อมใช้งานของแอปพลิเคชัน ตัวอย่างเช่นเมื่อเราตั้งค่าเว็บเซิร์ฟเวอร์โดยทั่วไปเว็บเซิร์ฟเวอร์แต่ละแห่งจะจัดเก็บข้อมูลไว้ในดิสก์ที่เชื่อมต่อภายในเครื่อง เมื่อปรับใช้ตัวควบคุมโดเมน Microsoft Active Directory จะดูแลการจำลองข้อมูล AD ในตัวควบคุมโดเมนทั้งหมด ในกรณีของบางอย่างเช่น SQL Server เราใช้ประโยชน์จากสิ่งต่างๆ Always On Availability Groups หรือ SIOS DataKeeper เพื่อให้ข้อมูลซิงค์กับดิสก์ที่เชื่อมต่อภายในเครื่อง
ยิ่งเราแจกจ่ายสำเนาข้อมูลในโซนความพร้อมใช้งานต่างๆมากเท่าไหร่เราก็จะมีโอกาสรอดจากความล้มเหลวได้มากขึ้นเท่านั้น
ตัวอย่างเช่นแอปพลิเคชันที่จัดเก็บข้อมูลในดิสก์สองแผ่นในโซนความพร้อมใช้งานที่แตกต่างกันจะได้รับประโยชน์จากความซ้ำซ้อนและแทนที่จะมีความพร้อมใช้งาน 99.9% มีแนวโน้มที่จะมีพื้นที่จัดเก็บถึง 99.9999%
1 – (.001 * .001) = .999999
ถ้าเราใส่มันลงในสมการก่อนหน้านี้รูปภาพจะดูสว่างขึ้นเล็กน้อย
.9999 * .9999 * .999999 = .9998
ความพร้อมใช้งาน 99.98% = ~ 9 นาทีของการหยุดทำงาน
ด้วยการทำซ้ำข้อมูลในหลาย AZ และหลายดิสก์เราจึงลดเวลาหยุดทำงานที่เกี่ยวข้องกับที่เก็บข้อมูลบนคลาวด์ได้อย่างมีประสิทธิภาพ
ความพร้อมใช้งานของแอปพลิเคชันและบริการที่ต้องพึ่งพา
คุณได้ทำทุกอย่างที่ทำได้เพื่อให้แน่ใจว่ามีการประมวลผลเครือข่ายและพื้นที่เก็บข้อมูล แต่ตัวแอปพลิเคชันล่ะ? แอปพลิเคชันบางตัวสามารถขยายขนาดและจัดเตรียมความซ้ำซ้อนได้โดยการทำโหลดบาลานซ์ระหว่างอินสแตนซ์หลายรายการของแอปพลิเคชันเดียวกัน ลองนึกถึงฟาร์มเว็บเซิร์ฟเวอร์ทั่วไปของคุณที่โดยทั่วไปคุณอาจโหลดคำขอเว็บสมดุลระหว่างเซิร์ฟเวอร์ห้าเครื่อง หากคุณสูญเสียเซิร์ฟเวอร์หนึ่งตัวตัวโหลดบาลานเซอร์จะลบเซิร์ฟเวอร์ออกจากการหมุนเวียนจนกว่าจะมีการตอบสนองอีกครั้ง
แอปพลิเคชันอื่น ๆ ต้องการการดูแลและตรวจสอบมากกว่านี้เล็กน้อย ใช้ SQL Server เป็นต้น โดยปกติ Always On Availability Groups หรือ Failover Cluster Instances จะใช้เพื่อตรวจสอบความพร้อมใช้งานของฐานข้อมูลและดำเนินการกู้คืนหากฐานข้อมูลไม่ตอบสนองเนื่องจากความล้มเหลวของแอปพลิเคชันหรือระดับระบบ แม้ว่าจะไม่มี SLA ที่เผยแพร่สำหรับโซลูชันความพร้อมใช้งานของ SQL Server แต่เป็นที่ยอมรับกันโดยทั่วไปว่าเมื่อกำหนดค่าอย่างเหมาะสมเพื่อความพร้อมใช้งานสูง SQL Server สามารถให้ความพร้อมใช้งานได้ 99.99%
คุณอาจพึ่งพาบริการบนคลาวด์อื่น ๆ เช่น Active Directory โฮสต์ DNS ที่โฮสต์ไมโครเซอร์วิสหรือแม้แต่ความพร้อมใช้งานของพอร์ทัลระบบคลาวด์เองทั้งหมดควรรวมอยู่ในสมการความพร้อมใช้งานโดยรวมของคุณ
สรุป
ความพร้อมใช้งานคือผลรวมของชิ้นส่วนที่เคลื่อนไหวทั้งหมด การข้ามไปในพื้นที่เดียวอาจส่งผลต่อความพร้อมใช้งานโดยรวมของแอปพลิเคชันของคุณอย่างทวีคูณ ใช้เวลาของคุณและตรวจสอบลิงก์ทั้งหมดในห่วงโซ่ความพร้อมใช้งานของคุณเพื่อหาจุดอ่อนรวมถึงการประมวลผลเครือข่ายพื้นที่เก็บข้อมูลแอปพลิเคชันและบริการที่ต้องพึ่งพา
โดยทั่วไปแล้วตัวเลขที่นำเสนอนี้หวังว่าจะเป็นสถานการณ์ในกรณีที่เลวร้ายที่สุดและความพร้อมใช้งานจริงของคุณควรเกิน SLA ที่เผยแพร่ ทำการบ้านและระวังบริการใด ๆ ที่ไม่สามารถรับประกันความพร้อมใช้งาน 99.99% ซึ่งเป็นเกณฑ์ทั่วไปของสิ่งที่ถือว่าพร้อมใช้งานสูง
ข้อผิดพลาดของมนุษย์และความปลอดภัยไม่ได้รับการแก้ไขในบทความนี้ คุณสามารถทำให้แอปพลิเคชันของคุณพร้อมใช้งานมากที่สุด อย่างไรก็ตามหากคุณไม่ได้ทำตามขั้นตอนเพื่อรักษาความปลอดภัยให้กับแอปพลิเคชันของคุณจากภัยคุกคามภายนอกและความผิดพลาดที่โง่เขลาของมนุษย์การเดิมพันทั้งหมดจะถูกปิดเมื่อถึงเวลาที่ว่าง
”)
