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

การคำนวณความพร้อมใช้งานของแอปพลิเคชันในคลาวด์

Date: ธันวาคม 18, 2020

การคำนวณความพร้อมใช้งานของแอปพลิเคชันในคลาวด์

การคำนวณความพร้อมใช้งานของแอปพลิเคชันในคลาวด์

เมื่อปรับใช้แอปพลิเคชันที่สำคัญทางธุรกิจในระบบคลาวด์คุณต้องแน่ใจว่าแอปพลิเคชันเหล่านี้พร้อมใช้งานสูง ข่าวดีก็คือหากคุณวางแผนอย่างถูกต้องคุณจะมีความพร้อมใช้งาน 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% ซึ่งเป็นเกณฑ์ทั่วไปของสิ่งที่ถือว่าพร้อมใช้งานสูง

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

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

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