SIOS SANless clusters High-availability Machine Learning monitoring
ซอฟต์แวร์ความพร้อมใช้งานสูงคือการประกันการหยุดทำงานของ SAPเราทุกคนต้องซื้อประกัน – สำหรับรถยนต์ของเราบ้านของเราชีวิตของเรา ไม่มีใครชอบที่จะจ่ายเงินสำหรับบริการที่เราหวังว่าเราจะไม่ต้องใช้ แต่เราทุกคนรู้ว่าเราควรจะมีมันในกรณี คนส่วนใหญ่ชะลอการประกันจนกระทั่งมีบางสิ่งที่เลวร้ายเกิดขึ้นซื้อที่ถูกที่สุดหรือทำการบ้านจริง ๆ แล้วซื้อจากคนที่พวกเขาไว้วางใจ กลุ่มสุดท้ายนี้มักจะมีค่าโดยสารที่ดีที่สุด
ในฐานะวิศวกรซอฟต์แวร์สำหรับประสบการณ์ของลูกค้ากับ SIOS ฉันมักจะช่วย บริษัท ที่กำลังโยกย้ายสภาพแวดล้อมการจัดกลุ่มที่มีความพร้อมใช้งานสูงในสถานที่ไปยังระบบคลาวด์
การโอนย้ายระบบคลาวด์เป็นกระบวนการไม่ใช่ปลายทาง เมื่อเราดึงดูดลูกค้าที่เปลี่ยนไปใช้ระบบคลาวด์นั้นมักจะมาช้าในกระบวนการวางแผนซึ่งไม่เหมาะ แต่ไม่ผิดปกติในการย้ายระบบคลาวด์ ด้านล่างนี้คือความท้าทายในการย้ายระบบคลาวด์หกประการที่เราเห็นบ่อยเกินไป
ใช้เวลานานแค่ไหนในการรับข้อมูลจากสถานที่ตั้งสู่ระบบคลาวด์ มันสามารถแตกต่างกันค่อนข้างมากขึ้นอยู่กับแอปพลิเคชันประเภทข้อมูลและผู้ให้บริการคลาวด์ของคุณ รายละเอียดที่มักถูกมองข้ามอย่างหนึ่งคือเวลาที่ใช้ในการซิงค์ข้อมูลจากโหนดหลักไปยังโหนดรองและในบางกรณีไปยังไซต์การกู้คืนความเสียหาย (DR) ลูกค้าที่ไม่บัญชีเวลาในการซิงค์ซ้ำจะถูกทำให้นิ้วหัวแม่มือของพวกเขาทวีคูณในขณะที่ข้อมูลทำซ้ำ
การถ่ายโอนข้อมูลภายในพื้นที่คลาวด์นั้นไม่มีค่าใช้จ่าย การถ่ายโอนข้อมูลระหว่างภูมิภาคจะมีค่าใช้จ่าย โดยทั่วไปแล้วเราจะเห็นสถาปัตยกรรมที่โหนดหลักและโหนดรองตั้งอยู่ในโซนความพร้อมใช้งานแบบคลาวด์ที่แยกต่างหากภายในภูมิภาค ค่าใช้จ่ายสามารถเพิ่มขึ้นอย่างมีนัยสำคัญเมื่อมีการแนะนำไซต์ DR เนื่องจากไซต์ DR จะอยู่ในภูมิภาคอื่นเสมอ การกู้คืนความเสียหายสำหรับแอปพลิเคชันที่มีข้อมูลจำนวนมากเช่น SAP NetWeaver อาจช่วยลดต้นทุนในการทำซ้ำในภูมิภาคต่างๆ
การจำลองแบบระหว่างภูมิภาคนำเสนอความท้าทายอื่น: ประเภทการจำลองแบบ การจำลองแบบอะซิงโครนัสหรือซิงโครนัสภายใน AZ ถูกกำหนดโดยข้อกำหนด RTO และ RPO ของลูกค้า ไม่ว่าจะมีขนาดของอินสแตนซ์หรือไม่การจำลองข้อมูลจะเกิดความล่าช้าเมื่อข้ามระหว่างภูมิภาค SIOS แนะนำให้จำลองแบบอะซิงโครนัสระหว่างภูมิภาคเพื่อลดผลกระทบของเวลาแฝงนั้น Concurrency Labs ให้ข้อมูลที่ชาญฉลาดเกี่ยวกับเวลาแฝงระหว่างภูมิภาค EC2
สามารถปรับใช้อิมเมจระบบปฏิบัติการสำเร็จรูปจากคลาวด์ ความสะดวกสบายนี้มาพร้อมกับค่าใช้จ่ายซึ่งเป็นการแนะนำปัจจัยอีกประการหนึ่งให้กับการจัดการการกำหนดค่า บริการ cloud-init ที่รวมอยู่ในอิมเมจ SuSE Enterprise Linux ที่ปรับให้เหมาะกับคลาวด์สามารถลบที่อยู่ IP เสมือนที่ผู้ใช้กำหนด ไม่มีอะไรจะหยุด PoC เหมือนที่อยู่ IP เสมือนที่หายไปทุกสองนาที!
ขนาดของคลาวด์คอมพิวติ้งมีความปลอดภัยมากกว่าธุรกิจที่สามารถจ่ายได้ในดาต้าเซ็นเตอร์ในสถานที่ ปริมาณงานบนคลาวด์ใช้ประโยชน์จากการรักษาความปลอดภัยที่ทันสมัยโดยที่ไม่รู้ตัว ตัวอย่างเช่นโดยค่าเริ่มต้น AWS EC2 อินสแตนซ์บล็อกการรับส่งข้อมูลใด ๆ ที่ไม่ได้ส่งหรือส่งไปยังอินสแตนซ์เอง นี่เป็นคุณสมบัติที่ยอดเยี่ยมสำหรับการรักษาความปลอดภัยเครือข่ายในคลาวด์ หากระบบต้องการ Network Address Translation (NAT) มาตรการรักษาความปลอดภัยเริ่มต้นของ EC2 จะทำให้ที่อยู่ IP ล้มเหลว การปิดใช้งานการตรวจสอบต้นทาง / ปลายทางจากคอนโซลจะช่วยแก้ปัญหา ขึ้นอยู่กับความคุ้นเคยของผู้ใช้กับ AWS ซึ่งอาจใช้เวลาระหว่างการคลิกไม่กี่ครั้งเพื่อรับการสนับสนุน การทำความเข้าใจกับรายละเอียดว่าระบบโต้ตอบในสภาพแวดล้อมเป็นกุญแจสำคัญในการย้ายระบบคลาวด์ที่ประสบความสำเร็จ
ลูกค้าที่มาจากระบบในสถานที่จะต้องได้รับการเตือนว่าทรัพยากรไม่ได้เป็นปัจจัย จำกัด อีกต่อไป ในระบบคลาวด์ระบบสามารถคัดลอกและใช้งานได้อย่างง่ายดายโดยแยกส่วนการผลิตสิ่งที่ไม่สำคัญในสถานที่ การเข้าถึงทรัพยากรไอทีตามความต้องการช่วยให้ UAT ของ HA และ DR ขยายเกิน "ปิดโหนดหลัก" เครือข่ายสามารถก่อวินาศกรรมเมล็ดสามารถตื่นตระหนกแม้ฐานข้อมูลอาจเสียหายและไม่มีสิ่งใดที่จะส่งผลกระทบต่อการผลิต! การระบุและทดสอบภาพจำลองเหล่านี้ปรับปรุงท่า HA และ DR
การดำเนินการโยกย้ายคลาวด์ที่ประสบความสำเร็จนั้นจำเป็นต้องมีการป้อนข้อมูลจากผู้มีส่วนได้ส่วนเสียทั้งหมด ความพร้อมใช้งานสูงและการกู้คืนความเสียหายเป็นประเด็นหลักของภาระงานระดับองค์กรใด ๆ ไม่ว่า SIOS จะเป็นส่วนหนึ่งของระบบปัจจุบันของคุณอยู่แล้วหรือจะเป็นส่วนหนึ่งของการย้ายระบบคลาวด์ในอนาคตของคุณขอให้เรามีส่วนร่วม!
-Harrison Howell วิศวกรซอฟต์แวร์สำหรับประสบการณ์ลูกค้า
ทำซ้ำโดยได้รับอนุญาตจาก SIOS
เราภูมิใจที่จะประกาศความพร้อมใช้งานของ SIOS Protection Suite สำหรับ Linux เวอร์ชัน 9.5 ผลิตภัณฑ์นี้แนะนำระบบอัตโนมัติขั้นสูงและการเฝ้าระวังการใช้งานทำให้เป็นซอฟต์แวร์การจัดกลุ่ม SAP S / 4HANA ที่ครอบคลุมและทันสมัยที่สุดในอุตสาหกรรม
เรารู้ว่าการสร้างคลัสเตอร์ S / 4HANA ด้วยตนเองเป็นเรื่องยุ่งยากเพียงใดตรวจสอบให้แน่ใจว่าบริการ HANA ทั้งหมดจะล้มเหลวไปยังตำแหน่งที่เหมาะสมและเริ่มต้นในลำดับที่ถูกต้อง ชั่วโมงของการเขียนสคริปต์การทดสอบและการทำให้รุนแรงขึ้น และเดิมพันสูง การทำให้ผิดพลาดอาจหมายถึงความล้มเหลวจะไม่เกิดขึ้นหรือแย่ลง – การหยุดทำงาน, การสูญเสียข้อมูล, การโทรซ้ำซ้อนของผู้ใช้จำนวนมาก
นั่นคือเหตุผลที่เราเพิ่มความพร้อมใช้งานของแอปพลิเคชันอัจฉริยะสำหรับการกำหนดค่าฐานข้อมูล SAP S / 4HANA สองโหนดที่ใช้การจำลองแบบระบบ HANA (HSR) เราได้สร้างรุ่นนี้เพื่อลดความยุ่งยากและความเสี่ยงออกจากการสร้างและจัดการคลัสเตอร์
เริ่มต้นจากการกำหนดค่าตัวช่วยสร้างที่ใช้งานง่ายซึ่งจะตรวจสอบอินพุตของคุณจริง ไม่มีการเขียนสคริปต์ด้วยตนเอง…หรือค้นหาการกดแป้นผิดพลาดเมื่อสิ่งต่างๆไม่ถูกต้อง
มันตรวจสอบกระบวนการทั้งหมดใน HANA stack จากแอปพลิเคชันไปจนถึงฮาร์ดแวร์เซิร์ฟเวอร์และเครือข่าย – ไม่ใช่แค่ตรวจสอบว่าเซิร์ฟเวอร์ทำงานเหมือนซอฟต์แวร์การทำคลัสเตอร์อื่น ๆ
และแตกต่างจากโซลูชันการจัดกลุ่มอื่น ๆ ที่ก่อให้เกิดความล้มเหลวสำหรับทุกสิ่งหาก SIOS Protection Suite ตรวจพบปัญหามันจะดำเนินการกู้คืนที่เหมาะสมโดยอัตโนมัติไม่ว่าจะเป็นการเริ่มบริการใหม่เพียงแค่การกู้คืนบนโหนดที่อยู่ในบริการ ปม
การพูดถึงการจัดการล้มเหลวจะช่วยให้มั่นใจได้ว่าจะมีการปรับปรุงวิธีปฏิบัติที่ดีที่สุดสำหรับ SAP โดยเฉพาะ ตัวอย่างเช่นทำให้แน่ใจว่าใน failover หรือ switchover ASCS จะไม่อยู่บนเซิร์ฟเวอร์ที่มีแอปพลิเคชันหลักหรือบนเซิร์ฟเวอร์เดียวกันกับ ERS
หากการกำหนดค่าที่ขับเคลื่อนด้วยตัวช่วยสร้างนั้นไม่ง่ายพอเรายังเพิ่มคุณสมบัติการโคลนอินเตอร์เฟสบรรทัดคำสั่ง (CLI) ใหม่ที่ช่วยให้คุณปรับใช้คลัสเตอร์ SIOS ได้ง่ายๆโดยการนำเข้าคำแนะนำ CLI สำหรับการกำหนดค่า คุณยังสามารถส่งออกคำสั่ง CLI ของคลัสเตอร์ที่มีอยู่เพื่อสร้างโคลนได้
ขณะนี้ SIOS Protection Suite สำหรับ Linux คุณสามารถสร้างคลัสเตอร์ความพร้อมใช้งานสูงได้อย่างรวดเร็วและง่ายดายเพื่อปกป้องแอปพลิเคชันใด ๆ ซึ่งรวมถึง SQL Server, Oracle, SAP และ S / 4HANA จากการหยุดทำงานและภัยพิบัติ
ทำซ้ำโดยได้รับอนุญาตจาก SIOS
แนวทางปฏิบัติที่ดีที่สุดในการตรวจสอบ EC2: การใช้ SIOS AppKeeper เพื่อปกป้อง NGINX Webservers บน Amazon EC2NGINX เป็นเว็บเซิร์ฟเวอร์ที่สามารถทำหน้าที่เป็น load balancer, reverse proxy, เป็นต้น เมื่อรวมเข้าด้วยกัน NGINX และ Apache ให้บริการมากกว่า 50% ของปริมาณข้อมูลบนเว็บ ทุกวันนี้หลาย บริษัท กำลังเรียกใช้ NGINX Open Source หรือ NGINX Plus webservers บนสภาพแวดล้อม Amazon EC2 โดยใช้ Amazon Linux, Red Hat Linux และ Ubuntu
ทุกคนยอมรับว่าเป็นวิธีปฏิบัติที่ดีที่สุดในการตรวจสอบแอปพลิเคชันเช่น NGINX บน EC2 และตอบสนองต่อความผิดปกติของระบบอย่างรวดเร็ว ผู้ใช้คาดหวังว่าจะสามารถเข้าถึงแอพพลิเคชั่นได้อย่างรวดเร็วและต่อเนื่อง
บริษัท หลายแห่งกำลังปรับใช้ Amazon CloudWatch เพื่อตรวจสอบแอปพลิเคชันของพวกเขาและแม้กระทั่งการสร้างระดับอัตโนมัติโดยการพัฒนาสคริปต์หรือโดยใช้ AWS Lambda แต่การกำหนดค่า Amazon CloudWatch อย่างถูกต้องด้วยตัวชี้วัดที่กำหนดเองและการตั้งค่า Amazon Lambda ต้องใช้ความเชี่ยวชาญด้านเทคนิคจำนวนหนึ่งซึ่งอาจเกินกว่า บริษัท หลายแห่ง และมีค่าใช้จ่ายและความพยายามในการบำรุงรักษาสคริปต์ใด ๆ
อีกทางเลือกหนึ่งคือการปรับใช้โซลูชันการตรวจสอบประสิทธิภาพแอปพลิเคชัน (APM) เช่นหนึ่งจาก New Relic, Dynatrace, Datadog หรือ LogicMonitor โซลูชั่นของ APM นั้นยอดเยี่ยม พวกเขาทำงานได้ดีมากในการเฝ้าดูระบบทั้งหมดของคุณและระบุสิ่งที่เกิดขึ้นและทำไม พวกเขาสร้างบันทึกที่สามารถแบ่งปันและตีความโดยทีมพัฒนาของคุณเพื่อสร้างปัญหาขึ้นใหม่และตรวจสอบให้แน่ใจว่ามันจะไม่เกิดขึ้นอีก แต่นี่คือสิ่งที่: โซลูชั่น APM ให้ข้อมูลจำนวนมากที่คุณต้องจัดเรียง (แยก "สัญญาณจากเสียงรบกวน") และพวกเขาไม่ทำอะไรเลยที่จะกู้คืนจากความล้มเหลวเมื่อเกิดขึ้น เครื่องมือ APM เป็นเพียงส่วนหนึ่งของการแก้ปัญหาเมื่อมันมาถึงการลดการหยุดทำงานสำหรับเว็บเซิร์ฟเวอร์ NGINX ของคุณ
แต่บาง บริษัท ไม่มีเจ้าหน้าที่ภายในหรือเครื่องมือในการตรวจสอบสภาพแวดล้อม EC2 ด้วยตนเอง นี่คือเหตุผลที่พวกเขาเลือกที่จะ outsource งานให้กับผู้ให้บริการที่มีการจัดการ มีประโยชน์อย่างมากในการทำงานกับ MSP เพื่อจัดการสภาพแวดล้อมของคุณเช่นไม่ต้องจ้างพนักงานเพิ่มเมื่อสภาพแวดล้อมของคุณขยายออกหรือไม่ต้องฝึกอบรมทีมของคุณเกี่ยวกับเทคโนโลยีใหม่ และ MSP มีความสุขกับประสิทธิภาพเนื่องจากสามารถกระจายการลงทุนไปยังลูกค้าหลายรายได้ แต่มีข้อเสีย ในบางกรณีคุณสามารถล็อคสัญญาที่มีค่าใช้จ่ายคงที่สูงและค่าใช้จ่ายอาจเพิ่มขึ้นหากมีปัญหาและพวกเขาต้องเลื่อนระดับเพื่อจัดการกับปัญหาเหล่านั้น และคุณจะสูญเสียความต่อเนื่องระหว่างทีมที่กำลังตรวจสอบสภาพแวดล้อมและผู้รับผิดชอบในการสร้างและปรับใช้แอปพลิเคชัน
ไม่ว่าคุณจะเลือกลงทุนในโซลูชั่น APM หรือให้บริการ MSP ภายนอกคุณยังต้องพิจารณาว่าคุณสามารถกู้คืนเซิร์ฟเวอร์เว็บ NGINX ของคุณได้อย่างรวดเร็วเพียงใดจากการหยุดทำงานหากเกิดขึ้นและเมื่อใด เราต้องการเสนอทางเลือกอื่น: การแก้ไขอัตโนมัติด้วย SOIS AppKeeper
ลูกค้าของเราหลายคนเลือกใช้ SIOS AppKeeper เพื่อปกป้องเว็บเซิร์ฟเวอร์ของ NGINX ในขณะที่พวกเขาสามารถเลือกโซลูชันแอพพลิเคชั่นการตรวจสอบประสิทธิภาพมาตรฐาน (APM) หรือโซลูชันการตรวจสอบบุคคลที่สามพวกเขาเลือกที่จะพึ่งพา AppKeeper เพื่อกู้คืนบริการโดยอัตโนมัติหรืออินสแตนซ์ EC2 ทั้งหมดหากเกิดความล้มเหลว เราจะดูที่สาเหตุบางประการและแบ่งปันวิดีโอสั้น ๆ กับคุณซึ่งแสดงให้เห็นว่า AppKeeper ทำงานกับ NGINX อย่างไร
SIOS AppKeeper เป็นบริการ SaaS ที่ง่ายต่อการติดตั้งและกำหนดค่าและตรวจสอบแอปพลิเคชันใด ๆ ที่ทำงานบน Amazon EC2 เช่นเว็บเซิร์ฟเวอร์ NGINX ของคุณและบริการ "nginx", "ตัวจัดการแคช" และ "คนงาน" เมื่อตรวจพบความผิดปกติ AppKeeper จะรีสตาร์ทบริการโดยอัตโนมัติและหากไม่ได้ผลก็จะรีบูตอินสแตนซ์ทั้งหมด ไม่มีการอ่านเพิ่มเติมผ่านบันทึกที่เจ็บปวดเพื่อระบุสาเหตุของความล้มเหลวหรือเพิ่มระดับให้กับนักพัฒนาเพื่อเริ่มบริการของคุณใหม่หรือค่าธรรมเนียมจ้างที่แพง AppKeeper มีฟังก์ชั่น "set-it-and-forget-it" เพื่อให้คุณมั่นใจได้ว่า NGINX webservers ของคุณปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดในการตรวจสอบ EC2 และทำงานอย่างถูกต้องหรือจะเริ่มต้นใหม่อย่างรวดเร็วหากพบปัญหาใด ๆ
ทุกวันนี้ บริษัท หลายร้อย บริษัท พึ่งพา AppKeeper เพื่อให้สภาพแวดล้อมคลาวด์ของตนทำงานต่อไป เราขอเชิญคุณให้ดูวิดีโอด่วนนี้เพื่อสาธิตวิธีที่ AppKeeper ปกป้องเว็บเซิร์ฟเวอร์ NGINX
หากคุณต้องการทดลองใช้ SIOS AppKeeper ด้วยตัวคุณเองเราขอเสนอการทดลองใช้ฟรี 14 วัน เพียงคลิกที่นี่เพื่อสมัคร
ด้วย AWS ที่มีส่วนแบ่งที่โดดเด่นของตลาดคลาวด์หลาย บริษัท กำลังโยกย้ายระบบในสถานที่ของพวกเขาไปยังคลาวด์กับ Amazon AWS ดังนั้นระบบที่ทำงานในสภาพแวดล้อม AWS ควรได้รับการจัดการอย่างไร
ในโพสต์บล็อกนี้เราจะแนะนำคุณสมบัติของ Amazon CloudWatch ซึ่งเป็นบริการตรวจสอบโดย AWS รวมถึงความท้าทายในการติดตั้งและวิธีแก้ไขปัญหา
เพื่อให้แน่ใจว่าคุณมีสภาพแวดล้อมคลาวด์ที่มั่นคงเป็นสิ่งสำคัญในการตรวจสอบความผิดปกติ (“ ความบกพร่องของระบบ”) ได้อย่างรวดเร็วและตอบสนองในเวลาที่เหมาะสม การตรวจสอบกลายเป็นงานที่สำคัญและจำเป็นสำหรับองค์กรใดก็ตามที่ย้ายไปยังคลาวด์ สิ่งนี้ไม่แตกต่างจากถ้าคุณจัดการแอปพลิเคชันและโครงสร้างพื้นฐานในสถานที่ ดังนั้นคุณควรตรวจสอบสภาพแวดล้อม AWS อย่างไร ทางเลือกหนึ่งคือใช้ Amazon CloudWatch ซึ่งตรวจสอบการใช้งาน CPU หน่วยความจำและดิสก์และแจ้งให้คุณทราบเมื่อเกินเกณฑ์ที่กำหนดไว้ล่วงหน้า นอกจากนี้คุณสามารถตั้งค่าการวัดของคุณเองเพื่อตรวจสอบรายการต่าง ๆ เช่นบันทึกแอปพลิเคชัน
ส่วนที่ดีที่สุดเกี่ยวกับ Amazon CloudWatch คือบริการโดย AWS มีความสัมพันธ์สูงกับ Amazon EC2 และบริการ AWS อื่น ๆ ดังนั้นจึงสามารถตอบสนองต่อการทำงานส่วนขยายและการเปลี่ยนแปลงข้อกำหนดได้อย่างรวดเร็วและสามารถรองรับการปรับขนาดอัตโนมัติ AWS ซึ่งเพิ่มหรือลดทรัพยากรโดยอัตโนมัติตามโหลด Amazon CloudWatch ให้การตรวจสอบที่แม่นยำซึ่งปรับให้เหมาะสมกับสถานการณ์เฉพาะของแต่ละสภาพแวดล้อม
ในขณะที่ Amazon CloudWatch เหมาะสมอย่างยิ่งสำหรับองค์กรที่มีวิศวกรระบบคลาวด์ที่มีประสบการณ์และทีม DevOps มีบางสิ่งที่ผู้ใช้ทั่วไปควรระวัง
Amazon CloudWatch มีประสิทธิภาพสำหรับการตรวจสอบสภาพแวดล้อม AWS ขององค์กร แต่ต้องใช้ทักษะและความรู้ระดับหนึ่งเพื่อกำหนดค่าและปรับใช้ โดยเฉพาะอย่างยิ่งเมื่อคุณตั้งค่าการวัดของคุณเองกำลังตั้งค่าการแจ้งเตือนหรือคำนึงถึงการปรับขนาดอัตโนมัติความซับซ้อนที่เพิ่มขึ้น ตัวอย่างเช่นหากคุณกำลังตั้งค่าการติดตามมันเป็นเรื่องง่าย แต่ถ้าคุณกำลังตั้งค่าอีเมลการรีบูตการปรับขนาดอัตโนมัติ ฯลฯ ขึ้นอยู่กับสถานการณ์ทรัพยากรอาจเป็นเรื่องยาก
หากคุณต้องการให้กระบวนการกู้คืนโดยอัตโนมัติพร้อมคำแนะนำเช่น "รีสตาร์ทเซิร์ฟเวอร์เมื่อเกิดข้อผิดพลาด" คุณต้องสร้างสถานการณ์การกู้คืนด้วยสคริปต์ AWS Lambda ที่ให้คำอธิบายโดยละเอียดเกี่ยวกับเงื่อนไขและการดำเนินการ ทีมของคุณคุ้นเคยกับ AWS Lambda อย่างไร
ข้อได้เปรียบที่สำคัญของ Amazon CloudWatch คือคุณสามารถตรวจสอบสภาพแวดล้อมของคุณได้อย่างใกล้ชิด แต่เพื่อที่จะทำเช่นนั้นคุณจะต้องออกแบบล่วงหน้าอย่างถูกต้องสำหรับแต่ละระบบว่ารายการใดที่จะต้องตรวจสอบและเมื่อใด งานออกแบบเหล่านี้อาจใช้เวลานาน แน่นอนว่าระบบภารกิจสำคัญของคุณจะต้องได้รับการตรวจสอบอย่างใกล้ชิดด้วยวิธีนี้ แต่รายละเอียดและความซับซ้อนในระดับนี้ไม่เหมาะสมสำหรับทุกระบบ สำหรับบางอย่างเช่นเว็บไซต์ภายในหรือเซิร์ฟเวอร์ WordPress คุณจะต้องลดค่าใช้จ่ายในการดำเนินงานและแรงงานของคุณ ในกรณีเช่นนี้เราขอแนะนำให้คุณพิจารณาเครื่องมือที่สามารถใช้งานและจัดการได้ง่ายขึ้น
สำหรับแอปพลิเคชั่นที่ไม่ได้เป็นภารกิจสำคัญเราขอแนะนำ SIOS AppKeeper จาก SIOS Technology AppKeeper ง่ายต่อการติดตั้งและกำหนดค่าและตรวจสอบบริการ (กระบวนการ) ของแอปพลิเคชันที่ทำงานบนอินสแตนซ์ EC2 AppKeeper จะรีสตาร์ทบริการโดยอัตโนมัติเมื่อตรวจพบข้อผิดพลาดและรีสตาร์ทอินสแตนซ์หากจำเป็น แม้แต่ผู้ใช้ที่ย้ายไปยังคลาวด์เป็นครั้งแรกสามารถตั้งค่า AppKeeper เพื่อตรวจสอบอินสแตนซ์ของ EC2 และกู้คืนโดยอัตโนมัติโดยไม่จำเป็นต้องมีทักษะการเขียนสคริปต์ที่ซับซ้อน
ด้วย AppKeeper ไม่จำเป็นต้องเลือกบริการส่วนบุคคลที่จะตรวจสอบ คุณเพียงแค่เริ่มต้นด้วยการเลือกอินสแตนซ์ EC2 ที่จะตรวจสอบและการกระทำที่คุณต้องการให้ดำเนินการโดยอัตโนมัติ คุณสามารถรับข้อมูลที่เฉพาะเจาะจงมากขึ้นเกี่ยวกับบริการที่จะตรวจสอบและวิธีการ แต่ AppKeeper ได้รับการออกแบบให้ง่ายต่อการกำหนดค่านอกกรอบ เมื่อตรวจพบข้อผิดพลาดหรือเรียกคืนโดยอัตโนมัติบันทึกของความล้มเหลวจะถูกบันทึกและจัดเก็บเพื่อให้สามารถตรวจสอบสาเหตุของความล้มเหลวได้ในภายหลัง
แทนที่จะใช้ Amazon CloudWatch เพื่อตรวจสอบทุกอย่างในสภาพแวดล้อม AWS ของคุณอย่างใกล้ชิดเราขอแนะนำให้คุณนำสินค้าคงคลังของสภาพแวดล้อมของคุณตาม SLA และข้อกำหนดการกู้คืนของคุณและใช้ SIOS AppKeeper เพื่อตรวจสอบระบบและแอพพลิเคชั่นที่คุณต้องการลดค่าใช้จ่าย
คอยติดตามการโพสต์บล็อกในอนาคตที่เราจะเข้าไปดูรายละเอียดที่มากขึ้นเปรียบเทียบการตั้งค่า CloudWatch และ AppKeeper เพื่อทำหน้าที่เดียวกัน