| ธันวาคม 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% จากสิ่งที่เราได้เรียนรู้ไปแล้วเรามาดูความพร้อมใช้งานของแอปพลิเคชันที่ใช้งานได้ในสองโซนความพร้อมใช้งาน ความพร้อมในการประมวลผล 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% ซึ่งเป็นเกณฑ์ทั่วไปของสิ่งที่ถือว่าพร้อมใช้งานสูง ข้อผิดพลาดของมนุษย์และความปลอดภัยไม่ได้รับการแก้ไขในบทความนี้ คุณสามารถทำให้แอปพลิเคชันของคุณพร้อมใช้งานมากที่สุด อย่างไรก็ตามหากคุณไม่ได้ทำตามขั้นตอนเพื่อรักษาความปลอดภัยให้กับแอปพลิเคชันของคุณจากภัยคุกคามภายนอกและความผิดพลาดที่โง่เขลาของมนุษย์การเดิมพันทั้งหมดจะถูกปิดเมื่อถึงเวลาที่ว่าง |
||||
| ธันวาคม 11, 2020 |
ใช้ Datadog สำหรับ Amazon EC2 Monitoring หรือไม่ จับคู่กับ SIOS AppKeeper สำหรับการแก้ไขอัตโนมัติ |
”)| {
“ instanceId”:“ {{EC2 Instance ID}}”, “ ชื่อ”:“ nginx” } |
ส่วนหัวที่กำหนดเอง: ทำเครื่องหมายในช่องและป้อนข้อมูลต่อไปนี้
| { “ ประเภทเนื้อหา”:“ application / json”, “ ยอมรับ”:“ application / json”, “ appkeeper-integration-token”:“ {{รับโทเค็นการรวม AppKeeper ภายนอกโทเค็นที่ได้รับใน}}” } |
เมื่อเสร็จแล้วให้กด“ บันทึก”
ขั้นตอนที่แปด: การเชื่อมต่อ AppKeeper กับการทดสอบ Synthetics
ต่อไปฉันต้องกำหนดค่า AppKeeper (การรวม Webhooks ที่ลงทะเบียนไว้) เพื่อเรียกใช้เมื่อมีการแจ้งเตือนการมอนิเตอร์ Synthetics เกิดขึ้น
เปิดกรณีทดสอบที่คุณตั้งค่าไว้ใน“ การกำหนดค่า Synthetic Monitoring ด้วย Datadog” จาก UX Monitoring> Synthetic Tests ในเมนู
เลือก“ แก้ไขรายละเอียดการทดสอบ” จากกระปุกเกียร์ด้านขวาบนและป้อนค่าต่อไปนี้ในช่อง“ 5. แจ้งทีมของคุณ” เพื่อบันทึกการเปลี่ยนแปลง
| @webhook – {{ชื่อการรวม Webhook ใน Datadog}} |
※คุณสามารถตั้งค่า“ แจ้งเตือนอีกครั้งหากจอภาพไม่ได้รับการแก้ไข”คุณสามารถลองใหม่ได้หาก AppKeeper ไม่สามารถกู้คืนได้ในครั้งแรกไม่จำเป็นสำหรับวัตถุประสงค์ในการทดสอบ แต่เราขอแนะนำให้คุณตั้งค่า[10 minutes]เป็น (ช่วงต่ำสุด)
การตั้งค่าเสร็จสมบูรณ์แล้ว
ขั้นตอนที่เก้า: ยืนยันการรวมโดยเรียกใช้การทดสอบอีกครั้ง
จากนั้นฉันยืนยันว่า AppKeeper จะคืนค่าเว็บเซิร์ฟเวอร์หาก Datadog ตรวจพบว่าไม่สามารถใช้งานได้
เปิดกรณีทดสอบการตรวจสอบ Synthetics ที่คุณเพิ่งตั้งค่าจาก UX Monitoring> Synthetic Tests ใน Datadog
คลิก "ดำเนินการทดสอบต่อ" ที่มุมขวาบนและเปิดการตรวจสอบ Synthetics
ตอนนี้ Datadog จะทำการตรวจสอบ Synthetics ในช่วงเวลาปกติ
ผลการทดสอบแสดงว่าเข้าถึงเซิร์ฟเวอร์ได้สำเร็จ
ต่อไปฉันสร้างความล้มเหลวของเว็บเซิร์ฟเวอร์หลอกเพื่อทดสอบการแก้ไขอัตโนมัติของ AppKeeper
เนื่องจากเป็นเรื่องยากที่จะทำให้เกิดความล้มเหลวอย่างแท้จริงฉันจึงหยุดบริการและสร้างสถานการณ์ที่คุณไม่สามารถดูหน้าเว็บได้ในการทำเช่นนี้ฉันเชื่อมต่อกับอินสแตนซ์ EC2 ที่ติดตั้งเซิร์ฟเวอร์ Nginx โดยใช้ SSH และหยุด Nginx
| sudo systemctl หยุด nginx |
หลังจากรอไม่นาน Datadog ตรวจพบว่าเว็บเซิร์ฟเวอร์ไม่สามารถเข้าถึงได้อีกต่อไป
หน้าการทดสอบสังเคราะห์ใน Datadog ยังแสดงว่ากรณีทดสอบล้มเหลว
หากกรณีทดสอบล้มเหลว Datadog จะแจ้ง AppKeeper ว่าการมอนิเตอร์ Synthetics ล้มเหลว
เมื่อ AppKeeper ได้รับการแจ้งเตือนมันจะพยายามรีสตาร์ท Nginx โดยอัตโนมัติ
ดังนั้นหากคุณรอสักครู่คุณจะเห็นว่าการตรวจสอบ Synthetics ของ Datadog จะผ่านไปอีกครั้ง
นอกจากนี้หากคุณลงชื่อเข้าใช้แดชบอร์ด AppKeeper คุณจะเห็นว่าได้ดำเนินการกู้คืนแล้ว
–
ในแบบฝึกหัดนี้ฉันใช้เว็บเซิร์ฟเวอร์ (Nginx) เป็นตัวอย่างในการตรวจจับความล้มเหลวของ Datadog โดยอัตโนมัติและเรียกคืนบริการด้วย AppKeeper
ระบบอัตโนมัติที่คล้ายกันสามารถทำได้โดยการรวม Datadog กับ EventBridge และ Lambda หรือโดยการสร้างสคริปต์ที่กำหนดเอง
อย่างไรก็ตามหากคุณเพิ่มอินสแตนซ์เป้าหมายบ่อยๆหรือรีสตาร์ทบริการที่หลากหลายต้นทุนและความซับซ้อนในการดูแล EventBridge และ Lambda หรือสคริปต์จะเพิ่มขึ้น
การผสานรวมที่พิสูจน์แล้วของ AppKeeper กับ Datadog และความสะดวกในการเพิ่มอินสแตนซ์เป้าหมายลงในแอปพลิเคชันของคุณทำให้ง่ายต่อการเพิ่มระบบอัตโนมัติให้กับสภาพแวดล้อม DevOps เพื่อลดเวลาหยุดทำงานของคุณ
หากคุณกำลังใช้ Datadog และต้องการทดลองใช้ AppKeeper's Restart API ก่อนอื่นโปรดลงชื่อสมัครทดลองใช้ฟรี 14 วันที่นี่ (คุณสามารถซื้อการสมัครใช้งานเมื่อคุณติดตั้งการทดลองใช้ฟรีแล้ว)จากนั้นคลิกที่นี่เพื่อขอทดลองใช้ฟรี เราจะแนะนำคุณตลอดขั้นตอนและมอบโทเค็นการประเมินให้คุณฟรีเพื่อช่วยคุณในการเริ่มต้น
ขอบคุณ.ฉันหวังว่าคุณจะใช้โอกาสนี้เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับ SIOS AppKeeper ซึ่งให้การตรวจสอบและกู้คืนแอปพลิเคชันที่ทำงานบน EC2 โดยอัตโนมัติ
– Tatsuya Hirao จากทีมเทคนิค SIOS Technology
ทำซ้ำโดยได้รับอนุญาตจาก SIOS
5 สัญญาณบ่งบอกว่าจะต้องใช้เวลามากกว่าบล็อกโพสต์เพื่อแก้ไขความพร้อมใช้งานสูงของคุณ
5 สัญญาณบ่งบอกว่าจะต้องใช้เวลามากกว่าบล็อกโพสต์เพื่อแก้ไขความพร้อมใช้งานสูงของคุณ
ป้ายอยู่ที่นั่น ไฟเตือนกะพริบในลำไส้ของคุณคุณสามารถรับรู้ได้ บางทีคุณอาจจะนอนไม่หลับปัญหาของคุณเกี่ยวกับความพร้อมใช้งานสูงนั้นลึก ๆ แต่บางทีคุณอาจจะไม่แน่ใจนัก
1. หากคุณคิดว่า SLA บนคลาวด์ของคุณคือสิ่งที่คุณต้องการสำหรับความพร้อมใช้งานที่สูง
โซลูชันระบบคลาวด์มีความก้าวหน้าอย่างมากในการเพิ่มความพร้อมใช้งานของฮาร์ดแวร์และความยืดหยุ่น อย่างไรก็ตามความพร้อมใช้งานสูงของแอปพลิเคชันต้องการมากกว่าการเลือกผู้ให้บริการไฮเปอร์ไวเซอร์หรือคลาวด์ที่เหมาะสม กลยุทธ์สำหรับความพร้อมใช้งานสูงของคุณไม่สามารถหยุดได้ด้วย SLA ที่จัดเตรียมโดยระบบคลาวด์หรือผู้ให้บริการการจำลองเสมือน ตามที่อ้างโดย Wired“ การหยุดให้บริการเกือบสี่วันของ Amazon ในเดือนเมษายน 2011 ไม่ได้ละเมิด EC2 SLA ของ Amazon ซึ่งตามคำถามที่พบบ่อยอธิบายว่า“ รับประกันความพร้อมให้บริการ 99.95% ภายในภูมิภาคตลอด 365 ช่วงเวลาต่อท้าย” ในบทความ DZone นี้ David Bermingham ของเราเองได้แจกแจงความแตกต่างระหว่าง SLA บนคลาวด์และความพร้อมใช้งานของแอปพลิเคชันโดยละเอียด หากคุณต้องการโครงสร้างพื้นฐานที่พร้อมใช้งานสูงต้องมีการตรวจสอบการกู้คืนและความยืดหยุ่นที่ชั้นข้อมูลและแอปพลิเคชันด้วย
2. หากคุณเพิ่งใช้คลัสเตอร์ความพร้อมใช้งานสูงที่มาพร้อมกับระบบปฏิบัติการโอเพนซอร์สของคุณ
ถ้าเป็นเช่นนั้นแสดงว่าคุณไม่ได้เลือกฐานข้อมูลของคุณตามสิ่งที่มาพร้อมกับระบบปฏิบัติการดังนั้นทำไมคุณถึงเลือกโซลูชัน HA ตามเกณฑ์นั้นเพียงอย่างเดียว เครื่องมือที่แถมมาช่วยเพิ่มความมั่นใจความเป็นไปได้และความสามารถ อย่างไรก็ตามแม้จะเข้าถึงได้ง่าย แต่เครื่องมือที่แถมมาและซอฟต์แวร์การทำคลัสเตอร์ OS ก็ไม่สามารถตอบสนองข้อกำหนด SLA, RPO, RTO และความพร้อมใช้งานของคุณได้เสมอไป หากองค์กรของคุณมีระบบปฏิบัติการร่วมกันทีมของคุณอาจต้องการความช่วยเหลือในการนำทางเครื่องมือต่างๆและทำความเข้าใจว่าพวกเขารวมเข้าด้วยกันอย่างไร มันเหมือนกับการเลือกปัตตาเลี่ยนป้องกันความเสี่ยงและดันเครื่องตัดหญ้าแบบหมุนไปทางซ้ายบนขอบถนนเพื่อให้มีรูปร่างเป็น "Azalea" ในหลุมที่ 13 พาร์ 5 (ที่ Augusta) เครื่องตัดหญ้าทั้งสองรุ่นออกแบบมาเพื่อตัดหญ้า แต่คุณมีเวลาเท่าไหร่? คุณจะจัดการกับความซับซ้อนได้อย่างไร? คุณจะเชื่อถืออะไร กลยุทธ์สำหรับความพร้อมใช้งานสูงของคุณต้องการมากกว่าการพิจารณาความสะดวกของสิ่งที่มาพร้อมกับระบบปฏิบัติการมิฉะนั้นคุณจะต้องใช้งาน MySQL แทน SAP HANA
3. หากคุณคิดว่าการให้สิทธิ์การใช้งานแอปพลิเคชันระดับองค์กรเช่น SQL Enterprise หรือ Oracle Enterprise เป็นสิ่งเดียวกับความพร้อมใช้งานระดับสูงขององค์กร
นอกเหนือจากค่าใช้จ่ายที่เพิ่มขึ้นใบอนุญาตแอปพลิเคชันระดับองค์กรจำนวนมากยังเพิ่มความสามารถของแอปพลิเคชันในการกู้คืนในสถานการณ์ที่มีความพร้อมใช้งานสูง อย่างไรก็ตามเป็นไปได้ยากมากที่ทั้งองค์กรของคุณจะใช้แอปพลิเคชันเดียว ความพร้อมใช้งานสูงของคุณต้องการมากกว่าโซลูชันฐานข้อมูลที่พร้อมใช้งานสูง คุณจะต้องมีโซลูชันการตรวจสอบและกู้คืนแอปพลิเคชันระดับองค์กรพร้อมการสนับสนุนที่หลากหลายสำหรับแอปพลิเคชันและฐานข้อมูลทั้งหมดของคุณ นอกจากนี้คุณจะต้องมีความสามารถในการจัดการและทำซ้ำไม่เพียง แต่ข้อมูลฐานข้อมูลเท่านั้น แต่ยังรวมถึงแอปพลิเคชันและข้อมูลการกำหนดค่าที่สำคัญอีกด้วย ความพร้อมใช้งานสำหรับฐานข้อมูลเดียวหรือแอปพลิเคชันง่ายๆเป็นสิ่งหนึ่ง แต่ HA สำหรับแอปพลิเคชันที่ซับซ้อนหลายส่วนและฐานข้อมูลที่รองรับนั้นแตกต่างกันมาก บริการเพิ่มเติมส่วนอื่น ๆ ที่ต้องประสานงานกันสถาปัตยกรรมที่ซับซ้อนมากขึ้นในการจัดระเบียบแนวทางปฏิบัติที่ดีที่สุดที่เฉพาะเจาะจงมากขึ้นที่จะปฏิบัติตามก่อนระหว่างและหลังการล้มเหลว / การสลับ มากกว่าใบอนุญาตองค์กรของคุณที่จ่ายให้
4. หากช่วงเวลาหยุดทำงานของคุณเพิ่มขึ้นและเวลาการทำงานของคุณลดลง
ก้าวของชีวิตที่เพิ่มขึ้นเรื่อย ๆ ในหลาย ๆ ด้าน ครั้งสุดท้ายที่ทีมของคุณกู้คืนจากการสำรองข้อมูลรีสตาร์ทแอปพลิเคชันที่ถือว่าสำคัญด้วยตนเองหรือรีสตาร์ทชุดเครื่องเสมือนหรือโหนดที่ล้มเหลว เหตุการณ์ไฟดับของคุณไม่สามารถก้าวไปข้างหน้าอย่างยั่งยืนต่อไปหรือความสามารถของทีมของคุณจะก้าวไปไกลกว่าการดับเพลิงไปสู่การป้องกันอัคคีภัยและการพิสูจน์อัคคีภัย “ คุณสามารถวิ่งได้นานมากเท่านั้น (Carey Nieuwhof)” สำหรับบางคนคุณผจญเพลิงมานานเกินไปและการดับของคุณกลายเป็นเรื่องปกติมากกว่าเวลาที่คุณไม่ได้ทำงาน
5. หากการทดสอบล้มเหลวครั้งแรกของคุณอยู่บนเซิร์ฟเวอร์ที่ใช้งานจริง
ลูกค้ารายล่าสุดตั้งข้อสังเกตว่าเป็นไปไม่ได้ที่จะทดสอบสถานการณ์ภัยพิบัติที่อาจเกิดขึ้นได้ทุกกรณี เมื่อซอฟต์แวร์ใหม่ถูกสร้างใช้งานอัปเดตและแก้ไขความท้าทายในความพร้อมใช้งานที่สูงขึ้นกำลังเพิ่มขึ้น แต่ข้อมูลการผลิตสดของคุณไม่ใช่สถานที่ที่จะค้นหาว่าอะไรที่เข้ากันได้ไม่ดี และในขณะที่ Go-Live และ Post-Go-Live จะมีส่วนแบ่งของความประหลาดใจอยู่เสมอ แต่การที่ไม่สามารถเฟลโอเวอร์และทำงานบนโหนดสำรองได้ไม่ควรเป็นหนึ่งในนั้น
บล็อกการกำจัดสิ่งสกปรกสามารถให้คำแนะนำและข้อมูลเชิงลึกที่เป็นประโยชน์แก่คุณเพื่อกำหนดนิยามใหม่และปรับปรุงความพร้อมใช้งานที่สูงขึ้นของคุณ แต่หากสัญญาณเตือนเกิดขึ้นว่าคุณได้แลกเปลี่ยนความพร้อมใช้งานที่แท้จริงสำหรับบางลักษณะของ 'เพียงพอ' ก็จะต้องใช้เวลามากกว่าบล็อกโพสต์หรือกำจัดทุกโพสต์ในบล็อกในโลกที่พร้อมใช้งานสำหรับเรื่องนั้นเพื่อแก้ไข HA ของคุณ
– Cassius Rhue รองประธานฝ่ายประสบการณ์ลูกค้า
ทำซ้ำโดยได้รับอนุญาตจาก SIOS
9 สัญญาณคุณมีปัญหาเกี่ยวกับความพร้อมใช้งานของแอปพลิเคชัน
SIOS AppKeeper พร้อมให้บริการแล้วใน AWS Marketplace
SIOS AppKeeper พร้อมให้บริการแล้วใน AWS Marketplace
ทำให้ง่ายต่อการเพิ่มการแก้ไขอัตโนมัติให้กับสภาพแวดล้อม DevOps ของคุณ
วันนี้เรารู้สึกตื่นเต้นที่จะประกาศว่าโซลูชัน SIOS AppKeeper ของเราพร้อมให้บริการแล้วใน AWS Marketplace ซึ่งเป็นแคตตาล็อกดิจิทัลที่มีรายการซอฟต์แวร์หลายพันรายการจากผู้จำหน่ายซอฟต์แวร์อิสระที่ช่วยให้ค้นหาทดสอบซื้อและปรับใช้ซอฟต์แวร์ที่ทำงานบน Amazon Web Services ได้อย่างง่ายดาย (AWS) ตอนนี้ผู้ใช้ปลายทางและสมาชิก AWS Partner Network (APN) เป็นเรื่องง่ายกว่าที่เคยในการทดลองรับและปรับใช้ SIOS AppKeeper เพื่อเพิ่มการแก้ไขอัตโนมัติให้กับสภาพแวดล้อม DevOps ของพวกเขาคลิกที่นี่เพื่อดู AppKeeper ใน AWS Marketplace
SIOS AppKeeper ตรวจสอบและปกป้องแอปพลิเคชันของคุณที่ทำงานบน Amazon EC2 อย่างต่อเนื่อง เราขาย AppKeeper ในญี่ปุ่นตั้งแต่ปี 2017 และได้นำบริการ SaaS เข้าสู่ตลาดสหรัฐอเมริกาเมื่อต้นปีนี้เราสร้าง AppKeeper เพื่อตอบสนองความต้องการที่เราได้ยินจากลูกค้าของเราที่ย้ายมาใช้ระบบคลาวด์และกังวลเกี่ยวกับการลดเวลาหยุดทำงานที่อาจเกิดขึ้นในขณะที่ต้องดิ้นรนกับทรัพยากรที่ จำกัด คลิกที่นี่หากคุณต้องการดูวิดีโอเกี่ยวกับความง่ายในการติดตั้งและใช้งาน AppKeeper
การตรวจสอบแอปพลิเคชัน AWS EC2 – SIOS AppKeeper | SIOS
ผู้ใช้ Amazon EC2 ประสบปัญหาการหยุดทำงานบ่อยเพียงใด จากข้อมูลลูกค้าของเราลูกค้าโดยเฉลี่ยที่มีอินสแตนซ์ Amazon EC2 เพียงสามเครื่องประสบปัญหาการหยุดทำงานอย่างน้อยเดือนละครั้งนั่นอาจเกิดจากความผิดพลาดในการกำหนดค่าซอฟต์แวร์เป็นต้น
นอกเหนือไปจากการตรวจสอบแอปพลิเคชันเพื่อเสนอการแก้ไขอัตโนมัติ
ผู้ใช้ AWS หลายรายกำลังปรับใช้โซลูชันการตรวจสอบประสิทธิภาพของแอปพลิเคชัน (APM) เช่นจาก AppDynamics, Datadog, Dynatrace หรือ New Relic เพื่อตรวจสอบสภาพแวดล้อม AWS ของตนแต่สิ่งเหล่านี้จะแจ้งเตือนคุณถึงความจริงที่ว่ามีบางอย่างเกิดขึ้นและเหตุใดจึงเกิดขึ้น พวกเขาไม่ได้ทำอะไรเพื่อลดเวลาหยุดทำงานของคุณ
นั่นคือสิ่งที่ AppKeeper เข้ามา หาก AppKeeper ตรวจพบการหยุดทำงานของบริการแอปพลิเคชันใด ๆ ที่ทำงานบน Amazon EC2 ระบบจะตอบสนองโดยอัตโนมัติโดยการรีสตาร์ทบริการที่ได้รับผลกระทบและรีบูตอินสแตนซ์หากจำเป็น AppKeeper ระบุ 85% ของความล้มเหลวของบริการแอปพลิเคชัน ลดความจำเป็นในการตรวจสอบจากภายนอกที่มีราคาแพงหรือสิ่งรบกวนสำหรับทีมไอทีของคุณด้วยการกู้คืนอัตโนมัติเรียนรู้เพิ่มเติมเกี่ยวกับระบบอัตโนมัติ APM จาก AppKeeper
ลูกค้า AWS ที่ใช้โซลูชัน APM อยู่แล้วและต้องการขยายฟังก์ชันการทำงานเพื่อรวมการแก้ไขอัตโนมัติหากตรวจพบเวลาหยุดทำงานของ Amazon EC2 และเมื่อตรวจพบการหยุดทำงานของ Amazon EC2 สามารถใช้ประโยชน์จาก Webhooks API ของ AppKeeper เพื่อรวมเข้ากับโซลูชัน APM ที่ตนเลือกได้
เหตุใดเราจึงตัดสินใจแสดงรายการ SIOS AppKeeper ใน AWS Marketplace
ที่ SIOS Technology Corporation เรามีความร่วมมือเชิงกลยุทธ์กับ Amazon AWS ตั้งแต่ปี 2014 โดยส่วนใหญ่เกี่ยวกับโซลูชัน SIOS DataKeeper และ SIOS LifeKeeper ที่มีความพร้อมใช้งานสูงSIOS Technology เป็นพันธมิตรขั้นสูงของ APN ในวันนี้และเราแบ่งปันลูกค้าร่วม 100 ราย
ตอนนี้เรามีข้อพิสูจน์ของลูกค้าสำหรับประสิทธิภาพของ SIOS AppKeeper แล้ว (นี่คือกรณีศึกษาล่าสุดที่คุณอาจชอบ) เราต้องการให้ลูกค้า Amazon และคู่ค้า APN ทดลองซื้อและใช้ AppKeeper ได้ง่ายขึ้นจากการประมาณการจำนวนมากมีลูกค้า AWS ที่ใช้งานซอฟต์แวร์จาก AWS Marketplace มากกว่า 200,000 รายซึ่งทุกคนใช้ประโยชน์จากความง่ายเพียงใดที่ AWS Marketplace ทำให้การค้นพบรับและใช้โซลูชันเสริมขณะที่พวกเขาดำเนินการเดินทางบนคลาวด์ต่อไป
และเพื่อนของเราที่ Amazon ไม่สามารถพูดได้ดีไปกว่านี้:“ เนื่องจากลูกค้าของเราโยกย้ายแอปพลิเคชันไปยังระบบคลาวด์มากขึ้นเรื่อย ๆ พวกเขามองหาความยืดหยุ่นในการปรับสมดุลระดับความพร้อมใช้งานกับต้นทุนในแอปพลิเคชันทั้งหมดของพวกเขา” Chris Grusz กล่าว ผู้อำนวยการ AWS Marketplace, Amazon Web Services, Inc. “ เรายินดีเป็นอย่างยิ่งที่ได้ต้อนรับ SIOS AppKeeper เข้าสู่ AWS Marketplace และเพื่อให้ลูกค้าของเรามีทางเลือกมากขึ้นเมื่อเกิดการเปลี่ยนแปลงด้านประสิทธิภาพ”
ลูกค้า AWS ที่สนใจในการปกป้องแอปพลิเคชัน EC2 จากการหยุดทำงานที่ไม่จำเป็นตอนนี้สามารถทดลองใช้ AppKeeper ด้วยตัวเองได้อย่างรวดเร็วและสามารถซื้อ AppKeeper ภายใต้แผนส่วนลด Amazon Enterprise ได้หากมีอยู่ราคาสำหรับ SIOS AppKeeper เริ่มต้นเพียง 40 เหรียญสหรัฐต่ออินสแตนซ์ต่อเดือน
พาร์ทเนอร์กำลังรวม AppKeeper เข้ากับโซลูชันของลูกค้า
ขณะนี้พันธมิตรหลายรายผสานรวม AppKeeper เข้ากับโซลูชันของลูกค้าและการมี AppKeeper พร้อมใช้งานใน AWS Marketplace ทำให้สมาชิก APN สามารถประเมินได้ง่ายขึ้นว่าโซลูชันนี้เหมาะสมกับธุรกิจและลูกค้าหรือไม่ Managed Service Providers (MSP) กำลังเริ่มรวม AppKeeper ไว้ในวิธีที่พวกเขาตรวจสอบและจัดการสภาพแวดล้อม AWS ของลูกค้าเพื่อลดเวลาหยุดทำงานและต้นทุนการดำเนินงานของตนเองISV อื่น ๆ กำลังรวมฟังก์ชันการแก้ไขอัตโนมัติของ AppKeeper เข้ากับโซลูชันการจัดการระบบคลาวด์ของตนเองและคู่ค้าที่ปรึกษาของ AWS เป็นบรรจุภัณฑ์ AppKeeper ในขณะที่พวกเขาพัฒนาและปรับใช้แอปพลิเคชันบน AWS ให้กับลูกค้า
สมาชิก APN ที่สนใจประเมินว่า AppKeeper เหมาะสมกับธุรกิจหรือไม่ควรติดต่อเราทางอีเมลที่ d-yoshioka@us.sios.com
เราหวังว่าคุณจะทดลองใช้ SIOS AppKeeper ด้วยตัวคุณเอง (เรามีการทดลองใช้ฟรี 14 วันและขั้นตอนการติดตั้งที่ง่ายดาย) และเข้าร่วมกับลูกค้าจำนวนมากที่ตอนนี้ผ่อนคลายโดยรู้ว่าพวกเขามีการแก้ไขอัตโนมัติเพื่อลดเวลาหยุดทำงานของ Amazon EC2 พวกเขาอาจได้สัมผัส