Archives for สิงหาคม 2020

จะเกิดอะไรขึ้นถ้าเรากำจัด Apache Downtime?

สิงหาคม 30, 2020 by Jason Aw Leave a Comment

**กำจัด * การหยุดทำงานของเว็บเซิร์ฟเวอร์ Apache ด้วย SIOS AppKeeper Monitoring**

ปัจจุบันเว็บเซิร์ฟเวอร์ Apache เป็นเว็บเซิร์ฟเวอร์ที่ได้รับความนิยมมากที่สุดบนอินเทอร์เน็ต บริษัท ต่างๆกำลังปรับใช้แอปพลิเคชันที่เน้นภารกิจสำคัญสำหรับลูกค้าที่สร้างขึ้นบน Apache โดยใช้แพลตฟอร์มคลาวด์เช่น Amazon AWS, Microsoft Azure และ Google Cloud Platform ดังนั้นคุณสามารถเดิมพันได้ว่าพวกเขาใช้เวลาและเงินจำนวนมากในการตรวจสอบแอปพลิเคชันเหล่านั้นและพยายามลดเวลาหยุดทำงาน แต่ถ้าเราบอกคุณว่าเราสามารถขจัดความจำเป็นในการแทรกแซงด้วยตนเองผ่านการตรวจสอบอัตโนมัติและการรีสตาร์ทแอปพลิเคชันเมื่อเว็บเซิร์ฟเวอร์ Apache ของคุณไม่ทำงาน

ก่อนที่เราจะไปดูว่าเราจะทำเช่นนั้นได้อย่างไรลองย้อนกลับไปสักครู่และดูตัวเลือกที่ บริษัท ต่างๆมีในการตรวจสอบและจัดการเว็บเซิร์ฟเวอร์ Apache และแอปพลิเคชันที่สำคัญเหล่านั้น

วิธีตรวจสอบและปกป้องเว็บเซิร์ฟเวอร์ Apache ของคุณจากการหยุดทำงานโดยไม่จำเป็น

ใครก็ตามที่ปรับใช้แอปพลิเคชันโดยใช้เว็บเซิร์ฟเวอร์ Apache อาจพิจารณาตรวจสอบความสมบูรณ์ของเว็บเซิร์ฟเวอร์ด้วยตนเองหรือจ้างงานนั้นให้บุคคลที่สาม

เมื่อพูดถึงการตรวจสอบแอปพลิเคชันระบบคลาวด์ที่ทำงานบน Amazon Web Services ตัวเลือกยอดนิยมคือการใช้ Amazon CloudWatch บริษัท บางแห่งกำลังขยายการทำงานของ CloudWatch ด้วยการสร้างระบบอัตโนมัติบางระดับโดยการพัฒนาสคริปต์หรือใช้ AWS Lambda แต่การกำหนดค่า Amazon CloudWatch อย่างเหมาะสมด้วยเมตริกที่กำหนดเองและการตั้งค่า AWS Lambda จำเป็นต้องใช้ความเชี่ยวชาญด้านเทคนิคจำนวนหนึ่งซึ่งอาจมีมากกว่า บริษัท หลายแห่ง จากนั้นมีค่าใช้จ่ายและความพยายามในการดูแลรักษาสคริปต์ใด ๆ เมื่อแอปพลิเคชันพัฒนาขึ้น

อีกทางเลือกหนึ่งคือการลงทุนในโซลูชัน Application Performance Monitoring (“ APM”) ที่ครอบคลุมจากผู้ขายเช่น New Relics, Dynatrace, DataDog หรือ LogicMonitor สิ่งเหล่านี้เหมาะสมมากหากคุณต้องการตรวจสอบมากกว่าแค่สภาพแวดล้อม AWS ของคุณ โซลูชัน APM สามารถกำหนดค่าได้มากและจะให้ข้อมูลจำนวนมากแก่คุณในแง่ของข้อมูลเกี่ยวกับสิ่งที่เกิดขึ้น

แต่คุณลดเวลาหยุดทำงานลงหรือยัง? อาจจะไม่. สิ่งที่คุณทำคือการลงทุนในระบบที่จะแจ้งเตือนคุณทันทีหากและเมื่อใดที่เว็บเซิร์ฟเวอร์ Apache ของคุณหยุดทำงานและจะทำให้คุณมีข้อมูลมากเกินไป (หรือ "แจ้งเตือนพายุ") เมื่อคุณพยายามทำให้สิ่งต่างๆกลับมาทำงานอีกครั้ง

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

จะต้องมีวิธีที่ดีกว่านี้

การตรวจสอบอัตโนมัติและรีสตาร์ทด้วย SIOS AppKeeper ช่วยลดเวลาหยุดทำงานของ Apache Webserver ได้อย่างไร

จากประสบการณ์ของลูกค้าของเรา บริษัท โดยเฉลี่ยที่มีอินสแตนซ์ EC2 เพียงสามแห่งประสบปัญหาการหยุดทำงานอย่างน้อยเดือนละครั้ง “ เว็บไซต์ล่ม! ปล่อยวางทุกอย่าง ค้นหาสิ่งที่ต้องทำ!” สิ่งที่คุณต้องทำคือลดความจำเป็นในการฝึกซ้อมดับเพลิงที่ไม่จำเป็นเหล่านี้

SIOS AppKeeper เป็นบริการ SaaS ที่ง่ายต่อการติดตั้งและกำหนดค่าและตรวจสอบบริการและแอปพลิเคชันที่ทำงานบน Amazon EC2 เช่นบริการ Apache httpd ของคุณ เมื่อตรวจพบความผิดปกติ AppKeeper จะรีสตาร์ทบริการโดยอัตโนมัติและหากไม่ได้ผลระบบจะรีบูตอินสแตนซ์ทั้งหมด ไม่ต้องอ่านบันทึกอีกต่อไปเพื่อระบุสาเหตุของความล้มเหลวหรือส่งต่อให้นักพัฒนาเริ่มบริการของคุณใหม่ หรือค่าจ้างแพง. AppKeeper มีฟังก์ชัน“ set-it-and-forget-it” เพื่อให้คุณสามารถกำจัดการหยุดทำงานได้

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

จะเกิดอะไรขึ้นถ้าเรากำจัด Apache Downtime

* จากข้อมูลลูกค้า AppKeeper ระบุ 85% ของความล้มเหลวของบริการแอปพลิเคชัน ดังนั้นในเกือบเก้าครั้งในสิบ AppKeeper จะส่งอีเมลแจ้งให้ลูกค้าทราบว่าระบบตรวจพบการหยุดทำงานและบริการเริ่มต้นใหม่หรือรีบูตอินสแตนซ์โดยอัตโนมัติ ไม่ดีไปกว่าการตื่นตระหนกและขุดดูไฟล์บันทึกก่อนที่จะรีสตาร์ททุกอย่างด้วยตนเองใช่หรือไม่

ดูโพสต์ที่เกี่ยวข้อง: เหตุใดการตรวจสอบแอปพลิเคชัน AWS EC2 จึงยากมาก

เคล็ดลับในการกู้คืน SIOS Protection Suite สำหรับ Linux Configuration Specifics

สิงหาคม 25, 2020 by Jason Aw Leave a Comment

เคล็ดลับในการกู้คืน SIOS Protection Suite สำหรับ Linux Configuration Specifics

เยี่ยมมาก "สุ่มเพื่อนร่วมงาน"! และโดยดีฉันไม่ได้หมายถึงงานดีจริงๆ และโดย "Random Coworker" ฉันหมายถึงผู้ชายที่ทำเครื่องหมายในช่องที่ไม่ควรเลือกหรือยกเลิกการเลือกช่องที่ควรเลือกชายหรือหญิงที่ข้ามข้อความและคำเตือนและมาตรการความปลอดภัย "โปรดยืนยัน" และทำลายการกำหนดค่า SIOS Protection Suite สำหรับ Linux ของคุณ

เราทุกคนเคยไปที่นั่น มันเป็นอุบัติเหตุ. อย่างไรก็ตามมันเกิดขึ้นมันเกิดขึ้น ทันใดนั้นคุณกำลังคิดหาสิ่งที่ต้องทำเพื่อกู้คืนการกำหนดค่าข้อมูลและ "อะไรก็ตาม" ก่อนที่เจ้านายจะรู้

ในฐานะรองประธานฝ่ายประสบการณ์ลูกค้าของ SIOS Technology Corp. ทีมงานของเรากำลังทำงานร่วมกับพันธมิตรและลูกค้าในการออกแบบและใช้ความพร้อมขององค์กรเพื่อป้องกันระบบของพวกเขาจากการหยุดทำงาน อุบัติเหตุเกิดขึ้นและประสบการณ์ล่าสุดของลูกค้าเตือนฉันว่าแม้จะมีการตรวจสอบและคำเตือนหลายครั้งของเราแม้แต่ผลิตภัณฑ์ SIOS Protection Suite สำหรับ Linux ก็ไม่ได้รับผลกระทบจากการเปลี่ยนแปลงการกำหนดค่าโดยไม่ได้ตั้งใจ แต่มีเคล็ดลับง่ายๆสำหรับการกู้คืนที่เร็วขึ้นจาก“ Random Coworker "ความผิดพลาดโดยบังเอิญ

วิธีการกู้คืน SIOS Protection Suite สำหรับ Linux หลังจากเปลี่ยนแปลงการกำหนดค่าโดยบังเอิญ

มาพร้อมกับ SIOS Protection Suite สำหรับ Linux (SPS-L) เป็นเครื่องมือที่เรียกว่า lkbackup ซึ่งอยู่ภายใต้ / opt / LifeKeeper / bin / lkbackup เครื่องมือตามชื่ออาจแนะนำสร้างข้อมูลสำรองของรายละเอียดการกำหนดค่า SPS-L หมายเหตุ: เครื่องมือนี้ไม่ได้สำรองข้อมูลแอปพลิเคชันทั้งหมด แต่จะสร้างการสำรองข้อมูลทั้งหมดสำหรับการกำหนดค่า SPS-L เช่น: คำจำกัดความของทรัพยากรการปรับแต่งค่าในไฟล์ / etc / default / LifeKeeper ลูกค้าสร้างขึ้นโดยทั่วไป แอ็พพลิเคชันสคริปต์แฟล็กที่เกี่ยวข้องกับสถานะของคลัสเตอร์พา ธ การสื่อสาร / นิยามคลัสเตอร์และอื่น ๆ

[root@baymax ~ ] # / opt / LifeKeeper / bin / lkbackup -c -f /root/mylkbackup-5.15.2020-v9.4.1 –cluster –ssh

ตัวอย่าง: lkbackup สร้างไวยากรณ์

สิ่งนี้จะสร้างไฟล์สำรองชื่อ mylkbackup-5.15.2020-v9.4.1 ภายใต้โฟลเดอร์ / root –cluster บอกให้ lkbackup สร้างไฟล์เดียวกันบนแต่ละโหนดคลัสเตอร์ –ssh ใช้โปรโตคอล ssh เพื่อเชื่อมต่อกับโหนดคลัสเตอร์แต่ละโหนด รายละเอียด lkbackup เพิ่มเติมอยู่ที่นี่:

ทีมบริการประสบการณ์ลูกค้าของเราขอแนะนำให้ทำการสำรองข้อมูลก่อนทำการเปลี่ยนแปลงการกำหนดค่า SPS-L เช่นการอัปเกรดการนำทรัพยากรออกหรือเพิ่มเติมหรือเปลี่ยนแปลงการกำหนดค่า

ดังนั้นเมื่อคุณต้องการกู้คืนคอนฟิกูเรชัน SPS-L การเปลี่ยนแปลงทำได้ง่ายเพียงแค่เรียกใช้ lkbackup อีกครั้ง

[root@baymax ~ ] # / opt / LifeKeeper / bin / lkbackup -x -f /root/mylkbackup-5.15.2020-v9.4.1 –cluster –ssh

ตัวอย่าง: lkbackup restore syntax

คุณสมบัติการสำรองข้อมูลอัตโนมัติจับไฟล์ lkbackup โดยอัตโนมัติ

แต่คุณจะทำอย่างไรถ้าคุณลืมเรียกใช้ lkbackup เพื่อสร้างไฟล์นี้ก่อนที่“ Random Coworker” ของคุณจะทำให้การตั้งค่าและการกำหนดค่า SPS-L ใช้เวลาไปหลายชั่วโมง คุณจะทำอย่างไรหาก“ Guy” หรือ“ Gal” ที่ตั้งค่า SPS-L อยู่ในช่วงพักร้อนลาเพื่อคลอดบุตรหรือลาคลอด จะเป็นอย่างไรถ้าคุณเป็น“ Random Coworker” และ Steve จากทีม Basis กำลังมุ่งหน้าไปตามโถงทางเดินเพื่อดูว่าสิ่งต่างๆเป็นอย่างไร สำหรับการติดตั้งส่วนใหญ่ SIOS จะเปิดใช้งานคุณลักษณะการสำรองข้อมูลอัตโนมัติระหว่างการติดตั้ง คุณลักษณะการสำรองข้อมูลอัตโนมัตินี้จะจับไฟล์ lkbackup ให้คุณโดยอัตโนมัติในเวลา 03.00 น. ตามเวลาท้องถิ่นภายใต้ /opt/LifeKeeper/config/auto-backup#.tgz

[root@baymax ~]# ls -ltr /opt/LifeKeeper/config/auto-backup.*

ตัวอย่าง. เอาต์พุตจากรายการ config / auto-backup

หากระบบของคุณได้รับการติดตั้งและกำหนดค่าอย่างถูกต้องการสำรองข้อมูลอัตโนมัติจะทำงานทุกคืนพร้อมที่จะครอบคลุมคุณเมื่อมีการประท้วง“ Random Coworker” ค้นหาการสำรองข้อมูลอัตโนมัติ SPS-L #. tgz ก่อนเกิดข้อผิดพลาดและใช้เครื่องมือ SPS-L lkbackup ดึงและกู้คืน SIOS Protection Suite สำหรับ Linux Configuration กลับสู่สถานะที่กำหนดค่าไว้ก่อนหน้านี้

[root@baymax ~ ] # lkstop; / opt / LifeKeeper / bin / lkbackup -c -f /opt/LifeKeeper/config/auto-backup.0.tgz

ตัวอย่าง: lkbackup restore syntax สำหรับ auto-backup

ทำซ้ำกับโหนดอื่นในคลัสเตอร์ตามต้องการ

บันทึก. หากระบบของคุณไม่ได้รับการกำหนดค่าให้สร้างไฟล์สำรองข้อมูลอัตโนมัติและปกป้องคุณจาก“ Random Coworker” ของคุณเอง SIOS จะเสนอบริการติดตั้งและกำหนดค่าและการตรวจสอบการกำหนดค่าที่ดำเนินการโดย SIOS Professional Services Engineer

– Cassius Rhue รองประธานฝ่ายประสบการณ์ลูกค้า

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

ทีละขั้นตอน: วิธีกำหนดค่าคลัสเตอร์ล้มเหลว SANless MySQL Linux ใน Amazon EC2

สิงหาคม 18, 2020 by Jason Aw Leave a Comment

ทีละขั้นตอน: วิธีกำหนดค่าคลัสเตอร์ล้มเหลว SANless MySQL Linux ใน Amazon EC2

ในคำแนะนำทีละขั้นตอนนี้ฉันจะนำคุณผ่านขั้นตอนทั้งหมดที่จำเป็นในการกำหนดค่าคลัสเตอร์ MySQL แบบ 2 โหนดที่พร้อมใช้งานสูง (รวมถึงเซิร์ฟเวอร์พยาน) ใน Elastic Compute Cloud ของ Amazon (Amazon EC2) คู่มือนี้มีทั้งภาพหน้าจอคำสั่งเชลล์และข้อมูลโค้ดตามความเหมาะสม ฉันคิดว่าคุณคุ้นเคยกับ Amazon EC2 และมีบัญชีอยู่แล้ว หากไม่เป็นเช่นนั้นคุณสามารถลงทะเบียนได้ตั้งแต่วันนี้ ฉันจะสมมติว่าคุณมีความคุ้นเคยพื้นฐานกับการดูแลระบบ Linux และแนวคิดการทำคลัสเตอร์แบบเฟลโอเวอร์เช่น Virtual IPs เป็นต้น

Failover clustering มีมาหลายปีแล้ว ในการกำหนดค่าทั่วไปโหนดสองโหนดขึ้นไปจะถูกกำหนดค่าด้วยพื้นที่เก็บข้อมูลที่ใช้ร่วมกันเพื่อให้แน่ใจว่าในกรณีที่เกิดความล้มเหลวบนโหนดหลักโหนดรองหรือเป้าหมายจะเข้าถึงข้อมูลที่เป็นปัจจุบันที่สุด การใช้พื้นที่เก็บข้อมูลที่ใช้ร่วมกันไม่เพียง แต่เปิดใช้งานจุดกู้คืนที่ใกล้เป็นศูนย์เท่านั้น แต่ยังเป็นข้อกำหนดบังคับสำหรับซอฟต์แวร์การทำคลัสเตอร์ส่วนใหญ่ อย่างไรก็ตามพื้นที่เก็บข้อมูลที่ใช้ร่วมกันมีความท้าทายหลายประการ ประการแรกมันเป็นความเสี่ยงจุดเดียวของความล้มเหลว หากพื้นที่เก็บข้อมูลที่ใช้ร่วมกันซึ่งโดยทั่วไปคือ SAN ล้มเหลวโหนดทั้งหมดในคลัสเตอร์จะล้มเหลว ประการที่สอง SAN อาจมีราคาแพงและซับซ้อนในการซื้อติดตั้งและจัดการ ประการที่สามพื้นที่จัดเก็บข้อมูลที่ใช้ร่วมกันในคลาวด์สาธารณะรวมถึง Amazon EC2 นั้นเป็นไปไม่ได้หรือไม่สามารถใช้งานได้จริงสำหรับ บริษัท ที่ต้องการรักษาความพร้อมใช้งานสูง (เวลาพร้อมใช้งาน 99.99%) เวลาในการกู้คืนที่ใกล้เป็นศูนย์และวัตถุประสงค์ของจุดกู้คืนและการป้องกันการกู้คืนจากภัยพิบัติ

ต่อไปนี้แสดงให้เห็นว่าการสร้างคลัสเตอร์ SANless ในคลาวด์นั้นง่ายเพียงใดเพื่อขจัดความท้าทายเหล่านี้ในขณะที่พบกับ HA / DR SLA ที่เข้มงวด ขั้นตอนด้านล่างใช้ฐานข้อมูล MySQL กับ Amazon EC2 แต่สามารถปรับขั้นตอนเดียวกันเพื่อสร้างคลัสเตอร์ 2 โหนดใน AWS เพื่อปกป้อง SQL, SAP, Oracle หรือแอปพลิเคชันอื่น ๆ

หมายเหตุ: มุมมองคุณสมบัติหน้าจอและปุ่มของคุณอาจแตกต่างจากภาพหน้าจอที่แสดงด้านล่างเล็กน้อย

1 สร้าง Virtual Private Cloud (VPC)
2 สร้างอินเทอร์เน็ตเกตเวย์
3 สร้างเครือข่ายย่อย (โซนความพร้อมใช้งาน)
4 กำหนดค่าตารางเส้นทาง
5 กำหนดค่า Security Group
6 เปิดตัวอินสแตนซ์
7 สร้าง Elastic IP
8 สร้างรายการเส้นทางสำหรับ IP เสมือน
9 ปิดการใช้งานการตรวจสอบต้นทาง / ปลายทางสำหรับ ENI
10 รับรหัสคีย์การเข้าถึงและคีย์การเข้าถึงลับ
11 การกำหนดค่าระบบปฏิบัติการ Linux
12 ติดตั้ง EC2 API Tools
13 ติดตั้งและกำหนดค่า MySQL
14 ติดตั้งและกำหนดค่าคลัสเตอร์
15 ทดสอบการเชื่อมต่อคลัสเตอร์

ภาพรวม

บทความนี้จะอธิบายวิธีสร้างคลัสเตอร์ภายในภูมิภาค Amazon EC2 เดียว โหนดคลัสเตอร์ (node1, node2 และเซิร์ฟเวอร์พยาน) จะอยู่ใน Availability Zones ที่แตกต่างกันเพื่อความพร้อมใช้งานสูงสุด นอกจากนี้ยังหมายความว่าโหนดจะอยู่ในเครือข่ายย่อยที่แตกต่างกัน

จะใช้ที่อยู่ IP ต่อไปนี้:

โหนด 1: 10.0.0.4
โหนด 2: 10.0.1.4
พยาน: 10.0.2.4
เสมือน / "ลอย" IP: 10.1.0.10

ขั้นตอนที่ 1: สร้าง Virtual Private Cloud (VPC)

ขั้นแรกสร้าง Virtual Private Cloud (aka VPC) VPC คือเครือข่ายแยกต่างหากภายในคลาวด์ของ Amazon ที่ทุ่มเทให้กับคุณ คุณสามารถควบคุมสิ่งต่างๆได้อย่างเต็มที่เช่นบล็อกที่อยู่ IP และเครือข่ายย่อยตารางเส้นทางกลุ่มความปลอดภัย (เช่นไฟร์วอลล์) และอื่น ๆ คุณจะเปิดตัวเครื่องเสมือน Azure Iaas (VMs) ของคุณในเครือข่ายเสมือนของคุณ

จากแดชบอร์ด AWS หลักเลือก“ VPC”

ภายใต้“ VPC ของคุณ” ตรวจสอบให้แน่ใจว่าคุณได้เลือกภูมิภาคที่เหมาะสมที่ด้านบนขวาของหน้าจอ ในคู่มือนี้จะใช้ภูมิภาค“ US West (Oregon)” เนื่องจากเป็นภูมิภาคที่มี Availability Zone 3 แห่ง สำหรับข้อมูลเพิ่มเติมเกี่ยวกับภูมิภาคและโซนความพร้อมใช้งานคลิกที่นี่

ตั้งชื่อ VPC และระบุบล็อก IP ที่คุณต้องการใช้ 10.0.0.0/16 จะใช้ในคู่มือนี้:

ตอนนี้คุณควรเห็น VPC ที่สร้างขึ้นใหม่บนหน้าจอ“ VPC ของคุณ”:

ขั้นตอนที่ 2: สร้างอินเทอร์เน็ตเกตเวย์

จากนั้นสร้างอินเทอร์เน็ตเกตเวย์ สิ่งนี้จำเป็นหากคุณต้องการให้อินสแตนซ์ (VM) ของคุณสามารถสื่อสารกับอินเทอร์เน็ตได้

ที่เมนูด้านซ้ายเลือกเกตเวย์อินเทอร์เน็ตแล้วคลิกปุ่มสร้างเกตเวย์อินเทอร์เน็ต ตั้งชื่อและสร้าง:

จากนั้นแนบอินเทอร์เน็ตเกตเวย์เข้ากับ VPC ของคุณ:

เลือก VPC ของคุณแล้วคลิกแนบ:

ขั้นตอนที่ 3: สร้างเครือข่ายย่อย (โซนความพร้อมใช้งาน)

จากนั้นสร้าง 3 เครือข่ายย่อย เครือข่ายย่อยแต่ละเครือข่ายจะอยู่ใน Availability Zone ของตนเอง อินสแตนซ์ 3 อินสแตนซ์ (VMs: node1, node2, พยาน) จะถูกเรียกใช้ในเครือข่ายย่อยแยกกัน (ดังนั้น Availability Zone) ดังนั้นความล้มเหลวของ Availability Zone จะไม่นำโหนดหลายโหนดออกจากคลัสเตอร์

ภูมิภาคตะวันตกของสหรัฐอเมริกา (ออริกอน) หรือที่เรียกว่า us-west-2 มี 3 โซนให้บริการ (us-west-2a, us-west-2b, us-west-2c) สร้างเครือข่ายย่อย 3 เครือข่ายหนึ่งในแต่ละโซนความพร้อมใช้งาน 3 โซน

ภายใต้ VPC Dashboard ไปที่ Subnets จากนั้นสร้าง Subnet:

ตั้งชื่อซับเน็ตแรก (“ Subnet1)” เลือกโซนความพร้อมใช้งาน us-west-2a และกำหนดบล็อกเครือข่าย (10.0.0.0/24):

ทำซ้ำเพื่อสร้างโซนความพร้อมใช้งานซับเน็ตที่สอง us-west-2b:

ทำซ้ำเพื่อสร้างซับเน็ตที่สามในโซนความพร้อมใช้งาน us-west-2c:

เมื่อดำเนินการเสร็จแล้วให้ตรวจสอบว่าเครือข่ายย่อย 3 เครือข่ายถูกสร้างขึ้นโดยแต่ละเครือข่ายมีบล็อก CIDR ที่แตกต่างกันและใน Availability Zone ที่แยกจากกันดังที่แสดงด้านล่าง:

ขั้นตอนที่ 4: กำหนดค่าตารางเส้นทาง

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

คลิกแก้ไข:

เพิ่มเส้นทางอื่น:

ปลายทางของเส้นทางใหม่จะเป็น“ 0.0.0.0/0” (อินเทอร์เน็ต) และสำหรับ Target ให้เลือก Internet Gateway ของคุณ จากนั้นคลิกบันทึก:

จากนั้นเชื่อมโยงเครือข่ายย่อย 3 เครือข่ายกับตารางเส้นทาง คลิกแท็บ“ Subnet Associates” และแก้ไข:

ทำเครื่องหมายในช่องถัดจากเครือข่ายย่อยทั้ง 3 เครือข่ายแล้วบันทึก:

ตรวจสอบว่าเครือข่ายย่อยทั้ง 3 เชื่อมโยงกับตารางเส้นทางหลัก:

ในภายหลังเราจะกลับมาและอัปเดตตารางเส้นทางอีกครั้งโดยกำหนดเส้นทางที่จะอนุญาตให้ทราฟฟิกสื่อสารกับ Virtual IP ของคลัสเตอร์ได้ แต่จะต้องดำเนินการหลังจากสร้างอินสแตนซ์ linux (VMs) แล้ว

ขั้นตอนที่ 5: กำหนดค่ากลุ่มความปลอดภัย

แก้ไข Security Group (ไฟร์วอลล์เสมือน) เพื่ออนุญาตการรับส่งข้อมูล SSH และ VNC ที่เข้ามา ทั้งสองจะถูกใช้ในภายหลังเพื่อกำหนดค่าอินสแตนซ์ linux ตลอดจนการติดตั้ง / กำหนดค่าซอฟต์แวร์คลัสเตอร์

ที่เมนูด้านซ้ายเลือก "กลุ่มความปลอดภัย" จากนั้นคลิกแท็บ "กฎขาเข้า" คลิกแก้ไข:

เพิ่มกฎสำหรับทั้ง SSH (พอร์ต 22) และ VNC โดยทั่วไป VNC ใช้พอร์ตใน 5900 ขึ้นอยู่กับว่าคุณกำหนดค่าอย่างไรดังนั้นเพื่อวัตถุประสงค์ของคู่มือนี้เราจะเปิดช่วงพอร์ต 5900-5910 กำหนดค่าตามการตั้งค่า VNC ของคุณ:

ขั้นตอนที่ 6: เปิดอินสแตนซ์

เราจะจัดเตรียมอินสแตนซ์ 3 รายการ (เครื่องเสมือน) ในคู่มือนี้ VM สองตัวแรก (เรียกว่า“ node1” และ“ node2”) จะทำหน้าที่เป็นโหนดคลัสเตอร์ที่มีความสามารถในการนำฐานข้อมูล MySQL และทรัพยากรที่เกี่ยวข้องมาทางออนไลน์ VM ตัวที่ 3 จะทำหน้าที่เป็นเซิร์ฟเวอร์พยานของคลัสเตอร์เพื่อเพิ่มการป้องกันจากสมองแยก

เพื่อให้แน่ใจว่ามีความพร้อมใช้งานสูงสุด VM ทั้ง 3 จะถูกปรับใช้ใน Availability Zone ต่างๆภายในภูมิภาคเดียว ซึ่งหมายความว่าแต่ละอินสแตนซ์จะอยู่ในเครือข่ายย่อยที่แตกต่างกัน

ไปที่แดชบอร์ด AWS หลักและเลือก EC2:

สร้าง“ node1”

สร้างอินสแตนซ์แรกของคุณ (“ node1”) คลิก Launch Instance:

เลือกการกระจาย linux ของคุณ ซอฟต์แวร์คลัสเตอร์ที่ใช้ในภายหลังรองรับ RHEL, SLES, CentOS และ Oracle Linux ในคู่มือนี้เราจะใช้ RHEL 7.X:

ปรับขนาดอินสแตนซ์ของคุณให้เหมาะสม เพื่อวัตถุประสงค์ของคู่มือนี้และเพื่อลดต้นทุนจึงใช้ขนาด t2.micro เนื่องจากมีสิทธิ์ระดับฟรี ดูข้อมูลเพิ่มเติมเกี่ยวกับขนาดและราคาของอินสแตนซ์ได้ที่นี่

จากนั้นกำหนดค่ารายละเอียดอินสแตนซ์ สำคัญ: อย่าลืมเปิดอินสแตนซ์แรก (VM) นี้ใน“ Subnet1” และกำหนดที่อยู่ IP ที่ถูกต้องสำหรับซับเน็ต (10.0.0.0/24) – เลือกต่ำกว่า 10.0.0.4 เนื่องจากเป็น IP ฟรีตัวแรกในซับเน็ต
หมายเหตุ: .1 / .2 / .3 ในเครือข่ายย่อยที่กำหนดใน AWS สงวนไว้และไม่สามารถใช้งานได้

จากนั้นเพิ่มดิสก์พิเศษให้กับโหนดคลัสเตอร์ (ซึ่งจะทำได้ทั้งบน“ node1” และ“ node2”) ดิสก์นี้จะจัดเก็บฐานข้อมูล MySQL ของเราและในภายหลังจะถูกจำลองแบบระหว่างโหนด

หมายเหตุ: คุณไม่จำเป็นต้องเพิ่มดิสก์เพิ่มเติมในโหนด "พยาน" เฉพาะ“ node1” และ“ node2” เพิ่มระดับเสียงใหม่และป้อนขนาดที่ต้องการ:

กำหนดแท็กสำหรับอินสแตนซ์ Node1:

เชื่อมโยงอินสแตนซ์กับกลุ่มความปลอดภัยที่มีอยู่ดังนั้นกฎไฟร์วอลล์ที่สร้างไว้ก่อนหน้านี้จะใช้งานได้:

คลิกเปิด:

สำคัญ: หากนี่เป็นอินสแตนซ์แรกในสภาพแวดล้อม AWS ของคุณคุณจะต้องสร้างคู่คีย์ใหม่ ไฟล์คีย์ส่วนตัวจะต้องถูกเก็บไว้ในตำแหน่งที่ปลอดภัยเนื่องจากจะต้องใช้เมื่อคุณ SSH เข้าสู่อินสแตนซ์ linux

สร้าง“ node2”

ทำซ้ำขั้นตอนด้านบนเพื่อสร้างอินสแตนซ์ลินุกซ์ที่สองของคุณ (node2) กำหนดค่าให้เหมือนกับ Node1 อย่างไรก็ตามตรวจสอบให้แน่ใจว่าคุณปรับใช้ใน“ Subnet2” (us-west-2b availability zone) ช่วง IP สำหรับ Subnet2 คือ 10.0.1.0/24 ดังนั้นจึงใช้ IP 10.0.1.4 ที่นี่:

อย่าลืมเพิ่มดิสก์ที่ 2 ใน Node2 ด้วย ควรมีขนาดเท่ากันกับดิสก์ที่คุณเพิ่มใน Node1:

ให้แท็กอินสแตนซ์ที่สอง…. “Node2”:

สร้าง "พยาน"

ทำซ้ำขั้นตอนด้านบนเพื่อสร้างอินสแตนซ์ linux ที่สามของคุณ (พยาน) กำหนดค่าให้เหมือนกับ Node1 & Node2 ทุกประการยกเว้นคุณไม่จำเป็นต้องเพิ่มดิสก์ที่ 2 เนื่องจากอินสแตนซ์นี้จะทำหน้าที่เป็นพยานให้กับคลัสเตอร์เท่านั้นและจะไม่นำ MySQL ออนไลน์

ตรวจสอบให้แน่ใจว่าคุณปรับใช้ใน“ Subnet3” (us-west-2c availability zone) ช่วง IP สำหรับ Subnet2 คือ 10.0.2.0/24 ดังนั้นจึงใช้ IP 10.0.2.4 ที่นี่:

หมายเหตุ: การกำหนดค่าดิสก์เริ่มต้นใช้ได้ดีสำหรับโหนดพยาน ไม่จำเป็นต้องใช้ดิสก์ที่ 2:

แท็กโหนดพยาน:

อาจใช้เวลาสักครู่ในการจัดสรรอินสแตนซ์ 3 รายการของคุณ เมื่อดำเนินการเสร็จแล้วคุณจะเห็นรายการว่าทำงานในคอนโซล EC2 ของคุณ:

ขั้นตอนที่ 7: สร้าง Elastic IP

จากนั้นสร้าง Elastic IP ซึ่งเป็นที่อยู่ IP สาธารณะที่จะใช้เพื่อเชื่อมต่อกับอินสแตนซ์ของคุณจากโลกภายนอก เลือก Elastic IPs ในเมนูด้านซ้ายจากนั้นคลิก“ Allocate New Address”:

เลือก Elastic IP ที่สร้างขึ้นใหม่คลิกขวาและเลือก“ Associate Address”:

เชื่อมโยง Elastic IP นี้กับ Node1:

ทำซ้ำกับอีกสองอินสแตนซ์หากคุณต้องการให้พวกเขาเข้าถึงอินเทอร์เน็ตหรือสามารถ SSH / VNC เข้ามาได้โดยตรง

ขั้นตอนที่ 8: สร้างรายการเส้นทางสำหรับ IP เสมือน

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

กำหนดเส้นทางใหม่ที่จะกำหนดเส้นทางการรับส่งข้อมูลไปยัง Virtual IP ของคลัสเตอร์ (10.1.0.10) ไปยังโหนดคลัสเตอร์หลัก (Node1)

จากแดชบอร์ด VPC เลือกตารางเส้นทางคลิกแก้ไข เพิ่มเส้นทางสำหรับ“ 10.1.0.10/32” โดยมีปลายทางเป็น Node1:

ขั้นตอนที่ 9: ปิดการใช้งานการตรวจสอบแหล่งที่มา / ปลายทางสำหรับ ENI

จากนั้นปิดใช้งานการตรวจสอบต้นทาง / ปลายทางสำหรับ Elastic Network Interfaces (ENI) ของโหนดคลัสเตอร์ของคุณ สิ่งนี้จำเป็นเพื่อให้อินสแตนซ์ยอมรับแพ็กเก็ตเครือข่ายสำหรับที่อยู่ IP เสมือนของคลัสเตอร์

ทำสิ่งนี้สำหรับ ENI ทั้งหมด

เลือก“ Network Interfaces” คลิกขวาที่ ENI แล้วเลือก“ Change Source / Dest Check”

เลือก“ ปิดการใช้งาน”:

ขั้นตอนที่ 10: รับรหัสคีย์การเข้าถึงและคีย์การเข้าถึงลับ

ต่อมาในคำแนะนำซอฟต์แวร์คลัสเตอร์จะใช้ AWS Command Line Interface (CLI) เพื่อจัดการรายการตารางเส้นทางสำหรับ Virtual IP ของคลัสเตอร์เพื่อเปลี่ยนเส้นทางการรับส่งข้อมูลไปยังโหนดคลัสเตอร์ที่ใช้งานอยู่ เพื่อให้สามารถใช้งานได้คุณจะต้องได้รับรหัสคีย์การเข้าถึงและคีย์การเข้าถึงลับเพื่อให้ AWS CLI สามารถตรวจสอบสิทธิ์ได้อย่างถูกต้อง

ที่ด้านบนขวาของ EC2 Dashboard ให้คลิกที่ชื่อของคุณจากนั้นเลือก“ Security Credentials” จากเมนูแบบเลื่อนลง:

ขยายส่วน“ Access Keys (Access Key ID และ Secret Access Key)” ของตารางแล้วคลิก“ Create New Access Key” ดาวน์โหลดไฟล์คีย์และจัดเก็บไฟล์ในตำแหน่งที่ปลอดภัย

ขั้นตอนที่ 11: กำหนดค่า Linux OS

เชื่อมต่อกับอินสแตนซ์ linux:

ในการเชื่อมต่อกับอินสแตนซ์ลินุกซ์ที่สร้างขึ้นใหม่ของคุณ (ผ่าน SSH) ให้คลิกขวาที่อินสแตนซ์และเลือก“ เชื่อมต่อ” ซึ่งจะแสดงคำแนะนำสำหรับการเชื่อมต่อกับอินสแตนซ์ คุณจะต้องมีไฟล์คีย์ส่วนตัวที่คุณสร้าง / ดาวน์โหลดในขั้นตอนก่อนหน้า:

ตัวอย่าง:

นี่คือที่ที่เราจะออกจาก EC2 Dashboard สักครู่และทำให้มือของเราสกปรกในบรรทัดคำสั่งซึ่งในฐานะผู้ดูแลระบบ Linux คุณควรคุ้นเคยในตอนนี้

คุณไม่ได้ให้รหัสผ่านรูทสำหรับ Linux VMs ของคุณใน AWS (หรือบัญชี“ ผู้ใช้ ec2” เริ่มต้น) ดังนั้นเมื่อคุณเชื่อมต่อแล้วให้ใช้คำสั่ง“ sudo” เพื่อรับสิทธิ์ root:

$ sudo su –

เว้นแต่คุณจะมีการตั้งค่าเซิร์ฟเวอร์ DNS อยู่แล้วคุณจะต้องสร้างรายการไฟล์โฮสต์บนเซิร์ฟเวอร์ทั้ง 3 เพื่อให้สามารถแก้ไขกันได้อย่างถูกต้องโดยใช้ nameEdit / etc / hosts

เพิ่มบรรทัดต่อไปนี้ที่ส่วนท้ายของไฟล์ / etc / hosts ของคุณ:

10.0.0.4 โหนด 1
10.0.1.4 โหนด 2
10.0.2.4 พยาน
10.1.0.10 mysql-vip

ปิดการใช้งาน SELinux

แก้ไข / etc / sysconfig / linux และตั้งค่า“ SELINUX = disabled”:

# vi / etc / sysconfig / selinux

# ไฟล์นี้ควบคุมสถานะของ SELinux บนระบบ # SELINUX = สามารถรับหนึ่งในสามค่านี้:

# enforcing – มีการบังคับใช้นโยบายความปลอดภัยของ SELinux

# permissive – SELinux พิมพ์คำเตือนแทนการบังคับใช้

# disabled – ไม่มีการโหลดนโยบาย SELinux

SELINUX = คนพิการ

# SELINUXTYPE = สามารถรับหนึ่งในสองค่านี้:

# เป้าหมาย – กระบวนการที่กำหนดเป้าหมายได้รับการป้องกัน # mls – การป้องกันความปลอดภัยหลายระดับ

SELINUXTYPE = การกำหนดเป้าหมาย

ตั้งชื่อโฮสต์

ตามค่าเริ่มต้นอินสแตนซ์ Linux เหล่านี้จะมีชื่อโฮสต์ที่อิงตามที่อยู่ IP ของเซิร์ฟเวอร์เช่น“ ip-10-0-0-4.us-west-2.compute.internal”

คุณอาจสังเกตเห็นว่าหากคุณพยายามแก้ไขชื่อโฮสต์ด้วยวิธี "ปกติ" (เช่นการแก้ไข / etc / sysconfig / network ฯลฯ ) หลังจากรีบูตแต่ละครั้งระบบจะเปลี่ยนกลับไปเป็นแบบเดิม !! ฉันพบชุดข้อความที่ยอดเยี่ยมในฟอรัมการสนทนาของ AWS ซึ่งอธิบายถึงวิธีรับชื่อโฮสต์ให้คงที่หลังจากรีบูต

ดูรายละเอียดที่นี่: https://forums.aws.amazon.com/message.jspa?messageID=560446

แสดงความคิดเห็นเกี่ยวกับโมดูลที่ตั้งชื่อโฮสต์ในไฟล์“ /etc/cloud/cloud.cfg” โมดูลต่อไปนี้สามารถแสดงความคิดเห็นโดยใช้ #

# – set_hostname

# – update_hostname

จากนั้นเปลี่ยนชื่อโฮสต์ของคุณใน / etc / hostname ด้วย

รีบูตโหนดคลัสเตอร์

รีบูตอินสแตนซ์ทั้ง 3 อินสแตนซ์เพื่อให้ SELinux ถูกปิดใช้งานและการเปลี่ยนแปลงชื่อโฮสต์จะมีผล

ติดตั้งและกำหนดค่า VNC (และแพ็คเกจที่เกี่ยวข้อง)

ในการเข้าถึง GUI ของเซิร์ฟเวอร์ linux ของเราและเพื่อติดตั้งและกำหนดค่าคลัสเตอร์ของเราในภายหลังให้ติดตั้งเซิร์ฟเวอร์ VNC รวมทั้งแพ็คเกจอื่น ๆ ที่จำเป็น (ซอฟต์แวร์คลัสเตอร์ต้องการ redhat-lsb และ patch rpms)

# yum group ติดตั้ง“ X Window System”

# yum group ติดตั้ง“ เซิร์ฟเวอร์พร้อม GUI”

# yum ติดตั้ง tigervnc-server xterm wget unzip patch redhat-lsb

# vncpasswd

URL ต่อไปนี้เป็นแนวทางที่ดีในการทำให้เซิร์ฟเวอร์ VNC ทำงานบน RHEL 7 / CentOS 7: สำหรับ RHEL 7.x / CentOS7.x:

https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-vnc-remote-access-for-the- gnome-desktop-on-centos-7

หมายเหตุ: การกำหนดค่าตัวอย่างนี้รัน VNC บนจอแสดงผล 2 (: 2, aka port 5902) และเป็นรูท (ไม่ปลอดภัย) ปรับตาม!

# cp /lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@:2.serv

# vi /etc/systemd/system/vncserver@:2.service

[Service]

พิมพ์ = ฟอร์ก

# ล้างไฟล์ที่มีอยู่ในสภาพแวดล้อม /tmp/.X11-unix ExecStartPre = / bin / sh -c ‘/ usr / bin / vncserver -kill% i> / dev / null 2> & 1 || :’

ExecStart = / sbin / runuser -l root –c“ / usr / bin / vncserver% i – เรขาคณิต 1024 × 768” PIDFile = / root / .vnc /% H% i.pid

ExecStop = / bin / sh -c ‘/ usr / bin / vncserver -kill% i> / dev / null 2> & 1 || :’

# systemctl daemon-reload

# systemctl เปิดใช้งาน vncserver @: 2. บริการ

# vncserver: 2 – เรขาคณิต 1024 × 768

สำหรับระบบ RHEL / CentOS 6.x:

# vi / etc / sysconfig / vncservers

VNCSERVERS =” 2: root” VNCSERVERARGS [2]=” – เรขาคณิต 1024 × 768″

# บริการ vncserver เริ่มต้น

# chkconfig vncserver บน

เปิดไคลเอนต์ VNC และเชื่อมต่อกับ <ElasticIP: 2> หากคุณไม่สามารถรับได้อาจเป็นไปได้ว่าไฟร์วอลล์ linux ของคุณกำลังขัดขวาง เปิดพอร์ต VNC ที่เราใช้ที่นี่ (พอร์ต 5902) หรือในตอนนี้ปิดไฟร์วอลล์ (ไม่แนะนำสำหรับสภาพแวดล้อมการผลิต):

# systemctl หยุด firewalld

# systemctl ปิดการใช้งาน firewalld

พาร์ติชันและฟอร์แมตดิสก์ "ข้อมูล"

เมื่ออินสแตนซ์ linux ถูกเรียกใช้และมีการเพิ่มดิสก์พิเศษให้กับแต่ละโหนดคลัสเตอร์เพื่อเก็บข้อมูลแอปพลิเคชันที่เราจะปกป้อง ในกรณีนี้เป็นฐานข้อมูล MySQL

ดิสก์ที่สองควรปรากฏเป็น / dev / xvdb คุณสามารถรันคำสั่ง“ fdisk -l” เพื่อตรวจสอบ คุณจะเห็นว่า
/ dev / xvda (OS) ถูกใช้แล้ว

# fdisk -l

# เริ่มต้นขนาดสิ้นสุดประเภท NameDisk / dev / xvda: 10.7 GB, 10737418240 ไบต์, 20971520 หน่วยภาค = ภาค 1 * 512 = 512 ไบต์
ขนาดเซกเตอร์ (ตรรกะ / ฟิสิคัล): 512 ไบต์ / 512 ไบต์ขนาด I / O (ต่ำสุด / เหมาะสมที่สุด): 512 ไบต์ / 512 ไบต์ประเภทป้ายชื่อดิสก์: gpt

1 2048 4095 1M ส่วนบูต BIOS
2 4096 20971486 10G Microsoft พื้นฐาน
ดิสก์ / dev / xvdb: 2147 MB, 2147483648 ไบต์, 4194304 เซกเตอร์หน่วย = เซ็กเตอร์ของ 1 * 512 = 512 ไบต์
ขนาดเซกเตอร์ (ตรรกะ / ฟิสิคัล): 512 ไบต์ / 512 ไบต์ขนาด I / O (ต่ำสุด / เหมาะสมที่สุด): 512 ไบต์ / 512 ไบต์

ที่นี่ฉันจะสร้างพาร์ติชัน (/ dev / xvdb1) จัดรูปแบบและติดตั้งที่ตำแหน่งเริ่มต้นสำหรับ MySQL ซึ่งก็คือ
/ var / lib / MySQL ทำตามขั้นตอนต่อไปนี้กับทั้ง“ node1” และ“ node2”:

# fdisk / dev / xvdb

ยินดีต้อนรับสู่ fdisk (util-linux 2.23.2)

การเปลี่ยนแปลงจะยังคงอยู่ในหน่วยความจำเท่านั้นจนกว่าคุณจะตัดสินใจเขียน โปรดใช้ความระมัดระวังก่อนใช้คำสั่งเขียน

อุปกรณ์ไม่มีตารางพาร์ติชันที่รู้จัก

การสร้าง DOS disklabel ใหม่ด้วยตัวระบุดิสก์ 0x8c16903a

Command (m สำหรับความช่วยเหลือ): n

ประเภทพาร์ติชัน:

p หลัก (0 หลัก, 0 ขยาย, 4 ฟรี) e ขยาย

เลือก (ค่าเริ่มต้น p): หน้า

หมายเลขพาร์ติชัน (1-4, ค่าเริ่มต้น 1): 1

ภาคแรก (2048-4194303, ค่าเริ่มต้น 2048): <enter>

ใช้ค่าเริ่มต้น 2048

ภาคสุดท้าย, + ภาคหรือ + ขนาด {K, M, G} (2048-4194303 ค่าเริ่มต้น 4194303): <enter>

ใช้ค่าเริ่มต้น 4194303

พาร์ติชัน 1 ของประเภท Linux และขนาด 2 GiB ถูกตั้งค่า

Command (m สำหรับความช่วยเหลือ): w

ตารางพาร์ติชั่นถูกเปลี่ยนแปลง!

เรียก ioctl () เพื่ออ่านตารางพาร์ติชันอีกครั้ง กำลังซิงค์ดิสก์

# mkfs.ext4 / dev / xvdb1
# mkdir / var / lib / mysql

บน node1 ติดตั้งระบบไฟล์:

# mount / dev / xvdb1 / var / lib / mysql

ต้องติดตั้ง EC2 API Tools (EC2 CLI) บนแต่ละโหนดคลัสเตอร์เพื่อให้ซอฟต์แวร์คลัสเตอร์สามารถจัดการตารางเส้นทางได้ในภายหลังทำให้สามารถเชื่อมต่อกับ Virtual IP ได้

ขั้นตอนที่ 12: ติดตั้ง EC2 API Tools

URL ต่อไปนี้เป็นคำแนะนำที่ดีเยี่ยมในการตั้งค่านี้:

http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/set-up-ec2-cli-linux.html

ขั้นตอนสำคัญมีดังนี้
ดาวน์โหลดคลายซิปและย้ายเครื่องมือ CLI ไปยังตำแหน่งมาตรฐาน (/ opt / aws):

# wget http://s3.amazonaws.com/ec2-downloads/ec2-api-tools.zip

# เปิดเครื่องรูด ec2-api-tools.zip

# mv ec2-api-tools-1.7.5.1 / / opt / aws /

# ส่งออก EC2_HOME =” / opt / aws”

หากยังไม่ได้ติดตั้ง java (เรียกใช้“ ซึ่ง java” เพื่อตรวจสอบ) ให้ติดตั้ง:

# yum ติดตั้ง java-1.8.0-openjdk

# ส่งออก JAVA_HOME =” / usr / lib / jvm / java-1.8.0-openjdk-1.8.0.71-

ตัวอย่าง (ขึ้นอยู่กับการกำหนดค่าเริ่มต้นของระบบ RHEL 7.2 ปรับให้เหมาะสม)

คุณจะต้องใช้ AWS Access Key และ AWS Secret Key เก็บค่าเหล่านี้ไว้เป็นประโยชน์เพราะจะต้องใช้ในภายหลังระหว่างการตั้งค่าคลัสเตอร์ด้วย! อ้างอิง URL ต่อไปนี้สำหรับข้อมูลเพิ่มเติม:

https://console.aws.amazon.com/iam/home?#security_credential

# ส่งออก AWS_ACCESS_KEY = your-aws-access-key-id

# ส่งออก AWS_SECRET_KEY = your-aws-secret-key

ทดสอบการทำงานของยูทิลิตี้ CLI:

# / opt / aws / bin / ec2- อธิบายภูมิภาค
ภูมิภาค eu-west-1 ec2.eu-west-1.amazonaws.com
ภูมิภาค ap- ตะวันออกเฉียงใต้ -1 ec2.ap-southeastern-1.amazonaws.com
ภูมิภาค ap- ตะวันออกเฉียงใต้ -2 ec2.ap-southeastern-2.amazonaws.com
ภูมิภาค eu-central-1 ec2.eu-central-1.amazonaws.com
ภูมิภาค ap-Northeast-2 ec2.ap-northeastern-2.amazonaws.com
ภูมิภาค ap-Northeast-1 ec2.ap-nortorth-1.amazonaws.com
ภูมิภาค us-east-1 ec2.us-east-1.amazonaws.com
ภูมิภาค sa-east-1 ec2.sa-east-1.amazonaws.com
ภูมิภาค us-west-1 ec2.us-west-1.amazonaws.com
ภูมิภาค us-west-2 ec2.us-west-2.amazonaws.com

ขั้นตอนที่ 13: ติดตั้งและกำหนดค่า MySQL

จากนั้นติดตั้งแพ็คเกจ MySQL เริ่มต้นฐานข้อมูลตัวอย่างและตั้งรหัสผ่าน“ root” สำหรับ MySQL ใน RHEL7.X แพ็คเกจ MySQL ถูกแทนที่ด้วยแพ็คเกจ MariaDB

บน“ node1”:

# yum ติดตั้ง mariadb mariadb-server

# mount / dev / xvdb1 / var / lib / mysql

# / usr / bin / mysql_install_db –datadir =” / var / lib / mysql /” –user = mysql

# mysqld_safe –user = root –socket = / var / lib / mysql / mysql.sock –port = 3306 –datadi

#

# # หมายเหตุ: คำสั่งถัดไปนี้อนุญาตให้เชื่อมต่อระยะไกลจากโฮสต์ใด ๆ ไม่ดี # echo“ update user set Host = ’%’ โดยที่ Host = ’node1′; สิทธิพิเศษมากมาย | mysql mys #

# #Set รหัสผ่านรูทของ MySQL เป็น "SIOS"

# echo“ อัปเดตชุดผู้ใช้รหัสผ่าน = รหัสผ่าน (‘SIOS’) โดยที่ User = ’root’; เปี่ยม

สร้างไฟล์คอนฟิกูเรชัน MySQL เราจะวางสิ่งนี้ไว้ในดิสก์ข้อมูล (ซึ่งจะถูกจำลองในภายหลัง –
/var/lib/mysql/my.cnf) ตัวอย่าง:

# vi /var/lib/mysql/my.cnf

[mysqld] datadir = / var / lib / MySQL

ซ็อกเก็ต = / var / lib / MySQL / mysql.sock

pid-file = / var / run / mariadb / mariadb.pid user = root

พอร์ต = 3306

# ขอแนะนำให้ปิดการใช้งานลิงก์สัญลักษณ์เพื่อป้องกันความเสี่ยงด้านความปลอดภัยต่างๆ symbolic-links = 0

[mysqld_safe]

บันทึกข้อผิดพลาด = / var / log / mariadb / mariadb.log pid-file = / var / run / mariadb / mariadb.pid

[client] ผู้ใช้ = รหัสผ่าน root = SIOS

ย้ายไฟล์คอนฟิกูเรชัน MySQL ดั้งเดิมออกไปถ้ามีอยู่:

# mv /etc/my.cnf /etc/my.cnf.orig

บน“ node2” คุณต้องติดตั้งแพ็คเกจ MariaDB / MySQL เท่านั้น ไม่จำเป็นต้องทำขั้นตอนอื่น ๆ : ใน“ node2”:

[root@node2 ~]# yum ติดตั้ง mariadb mariadb-server

ขั้นตอนที่ 14: ติดตั้งและกำหนดค่าคลัสเตอร์

ณ จุดนี้เราพร้อมที่จะติดตั้งและกำหนดค่าคลัสเตอร์ของเรา SIOS Protection Suite สำหรับ Linux (aka SPS-Linux) จะถูกใช้ในคู่มือนี้เป็นเทคโนโลยีการทำคลัสเตอร์ มีทั้งคุณลักษณะการทำคลัสเตอร์ความล้มเหลวที่มีความพร้อมใช้งานสูง (LifeKeeper) ตลอดจนการจำลองข้อมูลระดับบล็อกแบบเรียลไทม์ (DataKeeper) ในโซลูชันแบบบูรณาการเดียว SPS-Linux ช่วยให้คุณสามารถปรับใช้คลัสเตอร์“ SANLess” หรือที่เรียกว่าคลัสเตอร์“ ไม่ใช้ร่วมกัน” ซึ่งหมายความว่าโหนดคลัสเตอร์ไม่มีพื้นที่เก็บข้อมูลที่ใช้ร่วมกันเช่นเดียวกับกรณีของอินสแตนซ์ EC2

ติดตั้ง SIOS Protection Suite สำหรับ Linux

ทำตามขั้นตอนต่อไปนี้บน VM ทั้ง 3 (node1, node2, พยาน):

ดาวน์โหลดไฟล์อิมเมจการติดตั้ง SPS-Linux (sps.img) และรับใบอนุญาตทดลองใช้หรือซื้อใบอนุญาตถาวร ติดต่อ SIOS สำหรับข้อมูลเพิ่มเติม

คุณจะติดตั้งลูปแบ็คและเรียกใช้สคริปต์ "การตั้งค่า" ภายในเป็นรูท (หรือ "sudo su -" ตัวแรกเพื่อรับรูทเชลล์) ตัวอย่างเช่น:

# mkdir / tmp / ติดตั้ง

# mount -o loop sps.img / tmp / install

# cd / tmp / ติดตั้ง

# ./ติดตั้ง

ระหว่างสคริปต์การติดตั้งคุณจะได้รับแจ้งให้ตอบคำถามหลายข้อ คุณจะกด Enter เกือบทุกหน้าจอเพื่อยอมรับค่าเริ่มต้น สังเกตข้อยกเว้นต่อไปนี้:

บนหน้าจอที่ชื่อว่า“ High Availability NFS” คุณสามารถเลือก“ n” ได้เนื่องจากเราจะไม่สร้างเซิร์ฟเวอร์ NFS ที่พร้อมใช้งานสูง
ในตอนท้ายของสคริปต์การตั้งค่าคุณสามารถเลือกที่จะติดตั้งรหัสสิทธิ์การใช้งานรุ่นทดลองใช้ตอนนี้หรือในภายหลัง เราจะติดตั้งรหัสสัญญาอนุญาตในภายหลังเพื่อให้คุณสามารถเลือก“ n” ได้อย่างปลอดภัย ณ จุดนี้
ในหน้าจอสุดท้ายของ“ การตั้งค่า” ให้เลือก ARK (ชุดการกู้คืนแอปพลิเคชันเช่น“ ตัวแทนคลัสเตอร์”) ที่คุณต้องการติดตั้งจากรายการที่แสดงบนหน้าจอ
- ARK จำเป็นสำหรับ "node1" และ "node2" เท่านั้น คุณไม่จำเป็นต้องติดตั้งบน“ พยาน” นำทางรายการด้วยลูกศรขึ้น / ลงและกด SPACEBAR เพื่อเลือกสิ่งต่อไปนี้:
  - - lkDR – DataKeeper สำหรับ Linux
    - lkSQL – LifeKeeper MySQL RDBMS Recovery Kit
  - ซึ่งจะส่งผลให้ RPM เพิ่มเติมต่อไปนี้ติดตั้งบน“ node1” และ“ node2”:
    - steeleye-lkDR-9.0.2-6513.noarch.rpm steeleye-lkSQL-9.0.2-6513.noarch.rpm

ติดตั้งแพ็คเกจ Witness / Quorum

แพคเกจการสนับสนุนเซิร์ฟเวอร์ Quorum / Witness สำหรับ LifeKeeper (steeleye-lkQWK) รวมกับกระบวนการเฟลโอเวอร์ที่มีอยู่ของคอร์ LifeKeeper ทำให้ระบบเกิดความล้มเหลวได้อย่างมั่นใจมากขึ้นในสถานการณ์ที่อาจเกิดความล้มเหลวของเครือข่ายโดยรวม ซึ่งหมายความว่าสามารถทำได้อย่างมีประสิทธิภาพในขณะเดียวกันก็ช่วยลดความเสี่ยงของสถานการณ์ "สมองแตก" ได้อย่างมาก

ติดตั้งรอบต่อนาทีของพยาน / โควรัมบนทั้ง 3 โหนด (โหนด 1, โหนด 2, พยาน):

# cd / tmp / install / quorum

# รอบต่อนาที -Uvh steeleye-lkQWK-9.0.2-6513.noarch.rpm

บนโหนดทั้งหมด 3 โหนด (node1, node2, พยาน) แก้ไข / etc / default / LifeKeeper ตั้งค่า NOBCASTPING = 1
บนเซิร์ฟเวอร์ Witness เท่านั้น (“ พยาน”) แก้ไข / etc / default / LifeKeeper ตั้งค่า WITNESS_MODE = off / none

ติดตั้งแพ็คเกจ EC2 Recovery Kit

SPS-Linux มีคุณลักษณะเฉพาะที่อนุญาตให้รีซอร์สล้มเหลวระหว่างโหนดในโซนความพร้อมใช้งานและภูมิภาคต่างๆ ที่นี่ EC2 Recovery Kit (เช่นคลัสเตอร์เอเจนต์) ถูกใช้เพื่อจัดการตารางเส้นทางเพื่อให้การเชื่อมต่อกับ IP เสมือนถูกส่งไปยังโหนดคลัสเตอร์ที่ใช้งานอยู่

ติดตั้ง EC2 รอบต่อนาที (node1, node2):

# cd / tmp / install / amazon

# รอบต่อนาที -Uvh steeleye-lkECC-9.0.2-6513.noarch.rpm

ติดตั้งรหัสใบอนุญาต

ในทั้ง 3 โหนดใช้คำสั่ง“ lkkeyins” เพื่อติดตั้งไฟล์ลิขสิทธิ์ที่คุณได้รับจาก SIOS:

# / opt / LifeKeeper / bin / lkkeyins <path_to_file> / <ชื่อไฟล์> .lic

เริ่ม LifeKeeper

บนโหนดทั้ง 3 ใช้คำสั่ง“ lkstart” เพื่อเริ่มซอฟต์แวร์คลัสเตอร์:

# / opt / LifeKeeper / bin / lkstart

ตั้งค่าสิทธิ์ผู้ใช้สำหรับ LifeKeeper GUI

ในทั้ง 3 โหนดให้สร้างบัญชีผู้ใช้ linux ใหม่ (เช่น“ tony” ในตัวอย่างนี้) แก้ไข / etc / group และเพิ่มผู้ใช้ "tony" ไปยังกลุ่ม "lkadmin" เพื่อให้สิทธิ์เข้าถึง LifeKeeper GUI โดยค่าเริ่มต้นมีเพียง "root" เท่านั้นที่เป็นสมาชิกของกลุ่มและเราไม่มีรหัสผ่าน root ที่นี่:

# useradd โทนี่

# passwd tony

# vi / etc / group

lkadmin: x 1001: ราก tony

เปิด LifeKeeper GUI

ทำการเชื่อมต่อ VNC กับที่อยู่ Elastic IP (Public IP) ของ node1 จากการกำหนดค่า VNC จากด้านบนคุณจะเชื่อมต่อกับ <Public_IP>: 2 โดยใช้รหัสผ่าน VNC ที่คุณระบุไว้ก่อนหน้านี้ เมื่อเข้าสู่ระบบแล้วให้เปิดหน้าต่างเทอร์มินัลและเรียกใช้ LifeKeeper GUI โดยใช้คำสั่งต่อไปนี้:

# / opt / LifeKeeper / bin / lkGUIapp &

คุณจะได้รับแจ้งให้เชื่อมต่อกับโหนดคลัสเตอร์แรกของคุณ (“ node1”) ป้อนรหัสผู้ใช้ linux และรหัสผ่านที่ระบุระหว่างการสร้าง VM:

จากนั้นเชื่อมต่อกับทั้ง“ node2” และ“ พยาน” โดยคลิกปุ่ม“ เชื่อมต่อกับเซิร์ฟเวอร์” ที่ไฮไลต์ในภาพหน้าจอต่อไปนี้:

ตอนนี้คุณควรเห็นเซิร์ฟเวอร์ทั้ง 3 เซิร์ฟเวอร์ใน GUI โดยมีไอคอนเครื่องหมายถูกสีเขียวแสดงว่าเซิร์ฟเวอร์ออนไลน์และมีประสิทธิภาพดี:

สร้างเส้นทางการสื่อสาร

คลิกขวาที่“ node1” แล้วเลือก Create Comm Path

เลือกทั้ง“ node2” และ“ พยาน” จากนั้นทำตามวิซาร์ด สิ่งนี้จะสร้างเส้นทางการสื่อสารระหว่าง:

node1 และ node2 node1 และพยาน

ยังคงต้องสร้างเส้นทาง comm ระหว่าง node2 และพยาน คลิกขวาที่“ node2” แล้วเลือก Create Comm Path ทำตามวิซาร์ดและเลือก“ พยาน” เป็นเซิร์ฟเวอร์ระยะไกล:

ณ จุดนี้เส้นทาง comm ต่อไปนี้ถูกสร้างขึ้น:

node1 <—> node2 node1 <—> พยาน node2 <—> พยาน

ไอคอนหน้าเซิร์ฟเวอร์เปลี่ยนจาก "เครื่องหมายถูก" สีเขียวเป็น "ป้ายอันตราย" สีเหลือง เนื่องจากเรามีเส้นทางการสื่อสารระหว่างโหนดเท่านั้น

หาก VM มี NIC หลายตัว (ดูข้อมูลเกี่ยวกับการสร้าง Azure VM ที่มี NIC หลายรายการได้ที่นี่ แต่จะไม่ครอบคลุมในบทความนี้) คุณจะต้องสร้างเส้นทางการสื่อสารซ้ำซ้อนระหว่างแต่ละเซิร์ฟเวอร์

หากต้องการลบไอคอนคำเตือนไปที่เมนูมุมมองและยกเลิกการเลือก "Comm Path Redundancy Warning":

ผลลัพธ์:

ตรวจสอบเส้นทางการสื่อสาร

ใช้คำสั่ง“ lcdstatus” เพื่อดูสถานะของทรัพยากรคลัสเตอร์ รันคำสั่งต่อไปนี้เพื่อตรวจสอบว่าคุณได้สร้างเส้นทาง comm บนแต่ละโหนดไปยังเซิร์ฟเวอร์อีกสองเซิร์ฟเวอร์ที่เกี่ยวข้องอย่างถูกต้อง:

# / opt / LifeKeeper / bin / lcdstatus -q -d node1
ที่อยู่เครือข่ายเครื่อง / DEVICE STATE PRIO node2 TCP 10.0.0.4/10.0.1.4

ALIVE 1 พยาน TCP 10.0.0.4/10.0.2.4 ALIVE 1
# / opt / LifeKeeper / bin / lcdstatus -q -d node2
ที่อยู่เครือข่ายเครื่อง / DEVICE STATE PRIO node1 TCP 10.0.1.4/10.0.0.4

ALIVE 1 พยาน TCP 10.0.1.4/10.0.2.4 ALIVE 1
# / opt / LifeKeeper / bin / lcdstatus -q -d เป็นพยาน

ที่อยู่เครือข่ายเครื่อง / DEVICE STATE PRIO node1 TCP 10.0.2.4/10.0.0.4
ALIVE 1 node2 TCP 10.0.2.4/10.0.1.4 ALIVE 1

สร้างทรัพยากรคลัสเตอร์การจำลองข้อมูล (เช่น กระจกเงา)

จากนั้นสร้างรีซอร์ส Data Replication เพื่อจำลองพาร์ติชัน / var / lib / mysql จาก node1 (source) ไปยัง node2 (target) คลิกไอคอน "บวกสีเขียว" เพื่อสร้างทรัพยากรใหม่:

ทำตามวิซาร์ดด้วยการเลือกเหล่านี้:

โปรดเลือก Recovery Kit: Data Replication Switchback Type: intelligent

เซิร์ฟเวอร์: node1

ประเภทลำดับชั้น: จำลองระบบไฟล์ที่ออกจากระบบ

จุดติดตั้งที่มีอยู่: / var / lib / mysql

แท็กทรัพยากรการจำลองข้อมูล: datarep-mysql

แท็บทรัพยากรระบบไฟล์: / var / lib / mysql

ไฟล์บิตแมป: (ค่าเริ่มต้น)

เปิดใช้งานการจำลองแบบอะซิงโครนัส: ไม่ใช่

หลังจากสร้างทรัพยากรแล้ววิซาร์ด“ ขยาย” (เช่นกำหนดเซิร์ฟเวอร์สำรอง) จะปรากฏขึ้น

ใช้ตัวเลือกต่อไปนี้:

เซิร์ฟเวอร์เป้าหมาย: node2 Switchback ประเภท: Intelligent Template Priority: 1

ลำดับความสำคัญเป้าหมาย: 10 ดิสก์เป้าหมาย: / dev / xvdb1

แท็กทรัพยากรการจำลองข้อมูล: ไฟล์บิตแมป datarep-mysql: (ค่าเริ่มต้น)

เส้นทางการจำลองแบบ: 10.0.0.4/10.0.1.4 จุดต่อเชื่อม: / var / lib / mysql

รูทแท็ก: / var / lib / mysql

คลัสเตอร์จะมีลักษณะดังนี้:

สร้าง Virtual IP

จากนั้นสร้างทรัพยากรคลัสเตอร์ IP เสมือน คลิกไอคอน "บวกสีเขียว" เพื่อสร้างทรัพยากรใหม่:

ทำตามวิซาร์ดเพื่อสร้างรีซอร์ส IP ด้วยการเลือกเหล่านี้:

เลือก Recovery Kit: IP Switchback Type: Intelligent IP Resource: 10.1.0.10

เน็ตมาสก์: 255.255.255.0

อินเทอร์เฟซเครือข่าย: eth0

แท็กทรัพยากร IP: ip-10.1.0.10

ขยายทรัพยากร IP ด้วยการเลือกเหล่านี้:

ประเภทการสลับกลับ: ลำดับความสำคัญของเทมเพลตอัจฉริยะ: 1

ลำดับความสำคัญของเป้าหมาย: 10

ทรัพยากร IP: 10.1.0.10

เน็ตมาสก์: 255.255.255.0

อินเทอร์เฟซเครือข่าย: eth0

แท็กทรัพยากร IP: ip-10.1.0.10

คลัสเตอร์จะมีลักษณะเช่นนี้โดยสร้างทั้งทรัพยากร Mirror และ IP:

กำหนดค่า Ping List สำหรับทรัพยากร IP

โดยค่าเริ่มต้น SPS-Linux จะตรวจสอบความสมบูรณ์ของทรัพยากร IP โดยดำเนินการส่ง Ping ในสภาพแวดล้อมเสมือนและระบบคลาวด์จำนวนมากการส่ง Ping ไม่ทำงาน ในขั้นตอนก่อนหน้านี้เราตั้งค่า“ NOBCASTPING = 1” ใน
/ etc / default / LifeKeeper เพื่อปิดการตรวจสอบ ping การออกอากาศ แต่เราจะกำหนดรายการปิงแทน

นี่คือรายการของที่อยู่ IP ที่จะ ping ระหว่างการตรวจสอบความสมบูรณ์ของ IP สำหรับทรัพยากร IP นี้

ในคู่มือนี้เราจะเพิ่มเซิร์ฟเวอร์พยาน (10.0.2.4) ในรายการปิงของเรา

คลิกขวาที่ทรัพยากร IP (ip-10.1.0.10) และเลือก Properties:

คุณจะเห็นว่าในตอนแรกไม่มีการกำหนดค่ารายการ ping สำหรับซับเน็ต 10.1.0.0 ของเรา คลิก "แก้ไขรายการ Ping":

ป้อน“ 10.0.2.4” (ที่อยู่ IP ของเซิร์ฟเวอร์พยานของเรา) คลิก“ เพิ่มที่อยู่” และสุดท้ายคลิก“ บันทึกรายการ”:

คุณจะถูกส่งกลับไปยังแผงคุณสมบัติ IP และสามารถตรวจสอบได้ว่ามีการเพิ่ม 10.0.2.4 ในรายการ ping คลิกตกลงเพื่อปิดหน้าต่าง:

สร้างลำดับชั้นทรัพยากร MySQL

จากนั้นสร้างทรัพยากรคลัสเตอร์ MySQL ทรัพยากร MySQL มีหน้าที่หยุด / เริ่ม / ตรวจสอบฐานข้อมูล MySQL ของคุณ

ก่อนสร้างทรัพยากร MySQL ตรวจสอบให้แน่ใจว่าฐานข้อมูลกำลังทำงานอยู่ เรียกใช้“ ps -ef | grep sql” เพื่อตรวจสอบ

หากทำงานได้ดีก็ไม่ต้องทำอะไร ถ้าไม่เริ่มการสำรองฐานข้อมูล:

# mysqld_safe –user = root –socket = / var / lib / mysql / mysql.sock –port = 3306 –datadi

ทำตามวิซาร์ดเพื่อสร้างทรัพยากร IP ด้วยตัวเลือกเหล่านี้: ในการสร้างคลิกไอคอน "บวกสีเขียว" เพื่อสร้างทรัพยากรใหม่:

เลือก Recovery Kit: MySQL Database Switchback Type: Intelligent Server: node1

ตำแหน่งของ my.cnf: / var / lib / mysql

ตำแหน่งของไฟล์ปฏิบัติการ MySQL: / usr / bin

แท็กฐานข้อมูล: mysql

ขยายทรัพยากร IP ด้วยการเลือกต่อไปนี้:

เซิร์ฟเวอร์เป้าหมาย: node2 Switchback Type: Intelligent Template Priority: 1

ลำดับความสำคัญของเป้าหมาย: 10

ดังนั้นคลัสเตอร์ของคุณจะมีลักษณะดังนี้ โปรดสังเกตว่าทรัพยากรการจำลองข้อมูลถูกย้ายไปข้างใต้ฐานข้อมูลโดยอัตโนมัติ (สร้างการอ้างอิงโดยอัตโนมัติ) เพื่อให้แน่ใจว่าทรัพยากรถูกนำมาออนไลน์ก่อนฐานข้อมูลเสมอ:

สร้างทรัพยากร EC2 เพื่อจัดการตารางเส้นทางเมื่อเกิดข้อผิดพลาด

ในการสร้างคลิกไอคอน "บวกสีเขียว" เพื่อสร้างทรัพยากรใหม่:

ทำตามวิซาร์ดเพื่อสร้างรีซอร์ส EC2 ด้วยตัวเลือกเหล่านี้:

เลือก Recovery Kit: Amazon EC2 Switchback Type: Intelligent Server: node1

หน้าแรก EC2: / opt / aws

EC2 URL: ec2.us-west-2.amazonaws.com

คีย์การเข้าถึง AWS: (ป้อนคีย์การเข้าถึงที่ได้รับก่อนหน้านี้) คีย์ลับ AWS: (ป้อนรหัสลับที่ได้รับก่อนหน้านี้) ประเภททรัพยากร EC2: RouteTable (คลัสเตอร์แบ็กเอนด์)

ทรัพยากร IP: ip-10.1.0.10

แท็กทรัพยากร EC2: ec2-10.1.0.10

ขยายทรัพยากร IP ด้วยการเลือกต่อไปนี้:

เซิร์ฟเวอร์เป้าหมาย: node2 Switchback Type: Intelligent Template Priority: 1

ลำดับความสำคัญของเป้าหมาย: 10

แท็กทรัพยากร EC2: ec2-10.1.0.10

คลัสเตอร์จะมีลักษณะดังนี้ สังเกตว่ารีซอร์ส EC2 อยู่ใต้รีซอร์ส IP อย่างไร:

สร้างการพึ่งพาระหว่างทรัพยากร IP และทรัพยากรฐานข้อมูล MySQL

สร้างการพึ่งพาระหว่างทรัพยากร IP และทรัพยากรฐานข้อมูล MySQL เพื่อให้พวกเขาเฟลโอเวอร์ร่วมกันเป็นกลุ่ม คลิกขวาที่ทรัพยากร“ mysql” แล้วเลือก“ สร้างการพึ่งพา”:

ในหน้าจอต่อไปนี้ให้เลือกทรัพยากร“ ip-10.1.0.10” เป็นการอ้างอิง คลิกถัดไปและดำเนินการต่อผ่านตัวช่วยสร้าง:

ณ จุดนี้การกำหนดค่าคลัสเตอร์ SPS-Linux เสร็จสมบูรณ์ ลำดับชั้นของทรัพยากรจะมีลักษณะดังนี้:

ขั้นตอนที่ 15: ทดสอบการเชื่อมต่อคลัสเตอร์

ณ จุดนี้การกำหนดค่า Amazon EC2 และ Cluster ทั้งหมดของเราเสร็จสมบูรณ์แล้ว! ปัจจุบันทรัพยากรคลัสเตอร์แอ็คทีฟบน node1:

ทดสอบการเชื่อมต่อกับคลัสเตอร์จากเซิร์ฟเวอร์พยาน (หรืออินสแตนซ์ลินุกซ์อื่นหากคุณมี) SSH ในเซิร์ฟเวอร์พยาน“ sudo su -” เพื่อเข้าถึงรูท ติดตั้งไคลเอนต์ mysql หากจำเป็น:

[root@witness ~]# yum -y ติดตั้ง mysql

ทดสอบการเชื่อมต่อ MySQL กับคลัสเตอร์:

[root@witness ~]# mysql –host = 10.1.0.10 mysql -u root -p

เรียกใช้แบบสอบถาม MySQL ต่อไปนี้เพื่อแสดงชื่อโฮสต์ของโหนดคลัสเตอร์ที่ใช้งานอยู่:

MariaDB>[mysql] เลือก @@ ชื่อโฮสต์;

++

| @@ ชื่อโฮสต์ |

++

| โหนด 1 |

++

1 แถวในชุด (0.00 วินาที) MariaDB[mysql]>

ใช้ LifeKeeper GUI, เฟลโอเวอร์จาก Node1 -> Node2″ คลิกขวาที่ทรัพยากร mysql ใต้ node2 และเลือก“ In Service …”:

หลังจากล้มเหลวเสร็จสิ้นให้เรียกใช้แบบสอบถาม MySQL อีกครั้ง คุณจะสังเกตเห็นว่าไคลเอนต์ MySQL ตรวจพบว่าเซสชันหายไป (ระหว่างการล้มเหลว) และเชื่อมต่อใหม่โดยอัตโนมัติ:

ดำเนินการสืบค้น MySQL ต่อไปนี้เพื่อแสดงชื่อโฮสต์ของโหนดคลัสเตอร์ที่ใช้งานอยู่โดยยืนยันว่าขณะนี้“ node2” ทำงานอยู่:

MariaDB>[mysql] เลือก @@ ชื่อโฮสต์;

ข้อผิดพลาด 2006 (HY000): เซิร์ฟเวอร์ MySQL หายไปไม่มีการเชื่อมต่อ กำลังพยายามเชื่อมต่อใหม่ …

รหัสการเชื่อมต่อ: 12

ฐานข้อมูลปัจจุบัน: mysql

++

| @@ ชื่อโฮสต์ |

++

| โหนด 2 |

++

1 แถวในชุด (0.53 วินาที) MariaDB[mysql]>

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

บทเรียนใน Cloud High Availability จากภาพยนตร์

สิงหาคม 11, 2020 by Jason Aw Leave a Comment

บทเรียนใน Cloud High Availability จากภาพยนตร์

Joseph Lalonde จาก jmlalonde.com มีบล็อกที่เน้นบทเรียนความเป็นผู้นำจากภาพยนตร์ยอดนิยมเช่น Hancock, The Greatest Showman และ Frozen II เพื่อให้เครดิตกับบทเรียนความเป็นผู้นำที่สร้างแรงบันดาลใจของโจเซฟนี่คือบทเรียนที่มีความพร้อมใช้งานสูงสี่บทเรียนเกี่ยวกับการย้ายระบบคลาวด์จาก Disney’s Frozen II

บทเรียน Disney’s Frozen II และ Cloud Migration

ในแอนิเมชั่นผจญภัยของดิสนีย์ Frozen II ตัวละคร Anna, Elsa, Kristoff, Olaf และ Sven ออกจาก Arendelle เพื่อเดินทางไปยังป่าเก่าแก่ที่มีฤดูใบไม้ร่วงในดินแดนที่น่าหลงใหล ในการผจญภัยพวกเขาออกเดินทางเพื่อค้นหาต้นกำเนิดของพลังของเอลซ่าเพื่อกอบกู้อาณาจักรของพวกเขา นอกเหนือจากความสนุกสำหรับคุณพ่อของเด็กสาว 6 คนแล้วหนังยังมีความเป็นผู้นำชีวิตและบทเรียนที่มีความพร้อมสูงอีกด้วย

1 คุณไม่สามารถเข้าสู่การย้ายระบบคลาวด์ได้หากไม่ได้รับความช่วยเหลือที่เหมาะสม

เมื่อเอลซ่าแอนนาคริสตอฟโอลาฟและสเวนมาถึงสถานที่ซึ่งเสียงลึกลับเรียกพวกเขาพวกเขายืนอยู่นอกก้อนเมฆขนาดมหึมา เมื่อโอลาฟและคริสตอฟพยายามจะเข้าไปพวกเขาก็ถูกตีกลับและขับไล่ ก็ต่อเมื่อเอลซ่าเข้าใกล้เมฆด้วยเวทมนตร์ของเธอที่พอร์ทัลจะเปิดขึ้นและพวกเขาก็เข้ามา

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

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

2 สิ่งต่างๆจะไม่สมเหตุสมผลเมื่อคุณอายุมากขึ้นดังนั้นควรจัดทำเอกสารและทำซ้ำ

ในขณะที่เดินผ่านป่าอันน่าหลงใหล Olaf เริ่มพบกับปรากฏการณ์ประหลาดและความมหัศจรรย์ของป่า ในขณะที่เขาทำเขาเริ่มร้องเพลง:

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

เพลงจบลงด้วยการปลุกใจของ:

เพราะเมื่อคุณอายุมากขึ้น
ทุกอย่างสมเหตุสมผล
นี่เป็นเรื่องปกติ

หยุด. หากสิ่งต่าง ๆ ไม่สมเหตุสมผลกับคุณเมื่อคุณเริ่มต้นการเดินทางบนคลาวด์ให้ใช้เวลาในการทำให้เหมาะสม หากคุณกำลังใช้ความคิดแบบว่องไวให้เริ่มการสอบสวนในหัวข้อเอกพจน์หรือหัวข้อแห่งความสับสน ตัวอย่างเช่นหากคุณไม่เข้าใจความมหัศจรรย์ของแนวคิด VPC, Security Group, Availability Zone หรือ Set, Region หรือ Region to Region ในวันนี้พวกเขาจะมีความหมายน้อยลงในภายหลังเมื่อคุณกลับไปที่การกำหนดค่านี้ในอีกหลายเดือนต่อมา . หากผลการทดสอบไม่สมเหตุสมผลอย่าดำเนินการต่อแล้วเรียกใช้อีกครั้ง นอกจากนี้อย่าลืมจัดทำเอกสารสถาปัตยกรรมไม่ใช่แค่รายละเอียดที่คุณคิดว่ามีความสำคัญ แต่รายละเอียดที่ผู้สูงอายุที่ย้ายผ่านโครงการอื่น ๆ อีกหกโครงการและกำลังเผชิญกับเส้นตายก็อยากรู้เพื่อให้ทุกอย่างสมเหตุสมผล

3 อย่าวิ่งเข้าไปในกองไฟ เลือกโซลูชันความพร้อมใช้งานสูงบนคลาวด์ที่เหมาะสม

หลังจากแปรงด้วยวิญญาณแห่งลมป่าที่น่าหลงใหลก็ถูกไฟไหม้ ในขณะที่วิญญาณแห่งไฟกระจายความโกลาหลและไฟเอลซ่าก็พุ่งออกไปด้วยการระเบิดน้ำแข็งเพื่อทำให้ไฟเย็นลงและทำให้วิญญาณนี้สงบลง ด้วยความกระตือรือร้นแอนนาวิ่งเข้าไปในกองไฟข้างหลังพี่สาวและต้องได้รับความรอด ในที่สุดทั้งสองก็กลับมารวมตัวกันอีกครั้งเอลซ่าเตือนพี่สาวของเธอว่า“ คุณอย่าเพิ่งตามฉันไปในกองไฟ” แอนนาผู้ซ่าตอบว่า“ คุณไม่ต้องการให้ฉันตามคุณไปในกองไฟเหรอ? แล้วอย่าเข้าไปในกองไฟ!”

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

4 อย่าจมปลักอยู่กับอดีต: สิ่งที่คุณนำมาในการโยกย้ายระบบคลาวด์

มีเพลงที่ถักทอตลอดทั้งภาพยนตร์เรื่อง“ All is Found” พร้อมเสียงประสานอันเยือกเย็น -“ ดำดิ่งลงไปในเสียงของเธอ / แต่ไม่ไกลเกินไปมิฉะนั้นคุณจะจมน้ำตาย” เอลซ่าดำดิ่งสู่ห้วงลึกในขณะที่ภาพยนตร์เรื่องนี้พีคและการค้นหาและการสำรวจในอดีตของเธอทำให้ Frozen เธออ้าปากค้างครั้งสุดท้ายเพื่อเตือนและแจ้งพี่สาวของเธอ

ในฐานะหัวหน้าทีมประสบการณ์ลูกค้าของเราที่ SIOS Technology Corp. ฉันได้เห็นการใช้งานและการโยกย้ายจำนวนมากเกินไปจนติดอยู่ในกับดักการเปรียบเทียบ วลีจะเป็นเช่นนี้ "ในศูนย์ข้อมูลเก่าของเราเรา" หรือ "ระบบเก่าสามารถทำได้" อาจเป็นเรื่องจริงที่ระบบเก่าของคุณซึ่งเป็นระบบคงที่ทรัพยากรเฉพาะทีมขนาดใหญ่ระบบเครือข่ายเฉพาะและพื้นที่จัดเก็บ SAN ที่มีคุณสมบัติสูงซึ่งมีต้นทุนสูงสามารถทำเช่นนั้นได้ (แม้ว่าตามความเป็นจริงแล้วบางครั้งฉันก็เคยเห็นผ้าม่านหลุดออกมาและในสถานที่ก็ไม่ได้ทำเช่นนั้นจริงๆ) ในขณะที่คุณย้ายไปยังระบบคลาวด์ให้ทำความเข้าใจว่าอะไรเหมาะสมที่จะเลียนแบบในระบบคลาวด์และสิ่งที่ไม่มี ทำความเข้าใจว่าเหตุใดระบบจึงถูกสร้างขึ้นด้วยวิธีนี้ในสถานที่และใช้ความช่วยเหลือ“ บทที่ 1 และการเรียนรู้บทที่ 2 ทำการตัดสินใจที่สมเหตุสมผล

ซึ่งนำฉันไปสู่บทเรียนสุดท้าย

5 จะมีสองอาณาจักรเสมอ: ในสถานที่และในระบบคลาวด์

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

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

การไปที่ระบบคลาวด์ต้องใช้ทีมที่เหมาะสมเครื่องมือที่เหมาะสมและโซลูชันที่เหมาะสมรวมถึงกลยุทธ์และวางแผนที่จะไปถึงจุดนั้นโดยไม่ต้องฝ่าไฟ ในขณะที่คุณย้ายไปยังระบบคลาวด์จงเต็มใจที่จะเผชิญหน้ากับอดีตทำความเข้าใจและอย่าลืมว่าอย่าจมปลักอยู่ที่นั่น และเช่นเดียวกับพี่สาวทั้งสองของ Disney’s Frozen II คุณควรจดจำเรื่องราวขององค์กรที่สวยงามทุกเรื่องมี 2 ด้านในองค์กรและระบบคลาวด์อาจเป็นของคุณ

– Cassius Rhue รองประธานฝ่ายประสบการณ์ลูกค้า

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

เหตุใดการตรวจสอบแอปพลิเคชัน AWS EC2 จึงยากมาก

สิงหาคม 2, 2020 by Jason Aw Leave a Comment

เหตุใดการตรวจสอบแอปพลิเคชัน AWS EC2 จึงยากมาก

ขอแสดงความยินดี! คุณย้ายแอปพลิเคชันหลักไปยังระบบคลาวด์ AWS แล้ว หรือคุณกำลังพัฒนาแอพพลิเคชั่น“ ดั้งเดิมที่เป็นคลาวด์” และโฮสต์ไว้ในคลาวด์ บางทีคุณอาจได้รับประโยชน์จากความยืดหยุ่นในการปรับขนาดของ Amazon และสถาปัตยกรรมที่ยืดหยุ่น ทั้งสองวิธีตอนนี้คุณต้องการให้แน่ใจว่าแอปพลิเคชันเหล่านั้นยังคงทำงานอยู่หรือว่าคุณได้รับการแจ้งเตือนอย่างรวดเร็วหากเกิดอะไรขึ้น

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

วิธีการ จำกัด โซลูชันการตรวจสอบแอปพลิเคชัน EC2 ให้แคบลง

ขั้นตอนแรกในการค้นหาโซลูชันการตรวจสอบ EC2 ที่สมบูรณ์แบบของคุณควรเข้าใจความต้องการของคุณและความสามารถด้านเทคนิคของคุณเอง โซลูชันการตรวจสอบนั้นไม่เหมือนกันทั้งหมด

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

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

และความอยากด้านเทคนิคของคุณในการติดตั้งและจัดการแอปพลิเคชันอื่นคืออะไร? คุณรักการเขียนสคริปต์หรือไม่? หรือคุณต้องการบางสิ่งที่เป็น“ set-it-and-forget-it”?

การค้นหา“ โซลูชันการตรวจสอบประสิทธิภาพแอปพลิเคชัน” บน Google จะแสดงผลลัพธ์ 1,170,000,000 ผลลัพธ์! ข้ามไปที่ตลาด Amazon AWS และคุณจะพบผลิตภัณฑ์ 453 รายการในหมวดหมู่ DevOps – การตรวจสอบ การเข้าใจถึงความต้องการของคุณอย่างชัดเจนและความสามารถด้านเทคนิคของคุณเองจะช่วยให้การค้นหาของคุณแคบลง

การตรวจสอบแอปพลิเคชันที่ทำงานบน Amazon EC2 ด้วย Amazon CloudWatch หรือโซลูชั่น APM อื่น ๆ

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

อีกทางเลือกหนึ่งคือให้คุณประเมินและรับหนึ่งในโซลูชันการตรวจสอบประสิทธิภาพแอปพลิเคชัน (“ APM”) ที่มีวางจำหน่ายทั่วไปในท้องตลาดเช่น AppDynamics, Datadog, Dynatrace หรือ New Relic แต่โปรดคำนึงถึงความต้องการของคุณ คุณต้องการตรวจสอบในวงกว้างแค่ไหน? และคุณต้องการจะทำอะไรกับข้อมูลนั้น? คุณพร้อมที่จะรับการแจ้งเตือนหรือไม่ และโปรดทราบว่าโซลูชัน APM จำนวนมากไม่ได้ช่วยอะไรคุณในการกู้คืนเกินกว่าที่จะระบุปัญหา คุณยังต้องวางทุกอย่างเพื่อเริ่มบริการใหม่ด้วยตนเองหรือเริ่มต้นอินสแตนซ์ของคุณใหม่

ตรวจสอบแอปพลิเคชันที่ทำงานบน Amazon EC2 โดยใช้ SIOS AppKeeper

แต่มีวิธีอื่น SIOS AppKeeper เป็นบริการ SaaS ที่สามารถกำหนดค่าให้ค้นหาอินสแตนซ์ EC2 และบริการของตนโดยอัตโนมัติ จากนั้นจะใช้จำนวนการกระทำใด ๆ โดยอัตโนมัติหากและเมื่อมีการหยุดทำงาน ดังนั้นแทนที่จะได้รับการแจ้งเตือนว่ามีบางอย่างผิดปกติคุณจะได้รับแจ้งว่ามีบางอย่างเกิดขึ้นและได้รับการแก้ไขโดยอัตโนมัติ
ทำไม App_monitoring-ยาก 2-1024x470

SIOS AppKeeper เริ่มต้นเพียง US $ 40 ต่ออินสแตนซ์ต่อเดือน เราขอเชิญคุณดูวิดีโอสั้น ๆ นี้เพื่อดูว่าการติดตั้งและใช้ AppKeeper ง่ายแค่ไหน

เหตุใดการตรวจสอบแอปพลิเคชัน AWS EC2 จึงยากมาก

หนึ่งในลูกค้าของเราคือ Hobby Japan ซึ่งเป็น บริษัท สำนักพิมพ์ในโตเกียวเริ่มแรกใช้ Amazon CloudWatch แต่ทีมไอทีที่มีความเข้าใจไม่สามารถตอบสนองได้เร็วพอที่จะเตือน พวกเขาต้องการใช้ประโยชน์จากระบบอัตโนมัติและย้ายไปที่ SIOS AppKeeper ตั้งแต่ย้ายไปที่ AppKeeper พวกเขาไม่ประสบปัญหาใด ๆ หรือการหยุดทำงานที่ไม่คาดคิดกับอินสแตนซ์ EC2 ของพวกเขา นี่คือลิงค์ไปยังกรณีศึกษาของ Hobby Japan

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

Archives for สิงหาคม 2020

กำจัด * การหยุดทำงานของเว็บเซิร์ฟเวอร์ Apache ด้วย SIOS AppKeeper Monitoring

วิธีตรวจสอบและปกป้องเว็บเซิร์ฟเวอร์ Apache ของคุณจากการหยุดทำงานโดยไม่จำเป็น

การตรวจสอบอัตโนมัติและรีสตาร์ทด้วย SIOS AppKeeper ช่วยลดเวลาหยุดทำงานของ Apache Webserver ได้อย่างไร

เคล็ดลับในการกู้คืน SIOS Protection Suite สำหรับ Linux Configuration Specifics

วิธีการกู้คืน SIOS Protection Suite สำหรับ Linux หลังจากเปลี่ยนแปลงการกำหนดค่าโดยบังเอิญ

คุณสมบัติการสำรองข้อมูลอัตโนมัติจับไฟล์ lkbackup โดยอัตโนมัติ

ทีละขั้นตอน: วิธีกำหนดค่าคลัสเตอร์ล้มเหลว SANless MySQL Linux ใน Amazon EC2

ภาพรวม

ขั้นตอนที่ 1: สร้าง Virtual Private Cloud (VPC)

ขั้นตอนที่ 2: สร้างอินเทอร์เน็ตเกตเวย์

ขั้นตอนที่ 3: สร้างเครือข่ายย่อย (โซนความพร้อมใช้งาน)

ขั้นตอนที่ 4: กำหนดค่าตารางเส้นทาง

ขั้นตอนที่ 5: กำหนดค่ากลุ่มความปลอดภัย

ขั้นตอนที่ 6: เปิดอินสแตนซ์

ขั้นตอนที่ 7: สร้าง Elastic IP

ขั้นตอนที่ 8: สร้างรายการเส้นทางสำหรับ IP เสมือน

ขั้นตอนที่ 9: ปิดการใช้งานการตรวจสอบแหล่งที่มา / ปลายทางสำหรับ ENI

ขั้นตอนที่ 10: รับรหัสคีย์การเข้าถึงและคีย์การเข้าถึงลับ

ขั้นตอนที่ 11: กำหนดค่า Linux OS

เชื่อมต่อกับอินสแตนซ์ linux:

ปิดการใช้งาน SELinux

ตั้งชื่อโฮสต์

รีบูตโหนดคลัสเตอร์

ติดตั้งและกำหนดค่า VNC (และแพ็คเกจที่เกี่ยวข้อง)

พาร์ติชันและฟอร์แมตดิสก์ "ข้อมูล"

ขั้นตอนที่ 12: ติดตั้ง EC2 API Tools

ขั้นตอนที่ 13: ติดตั้งและกำหนดค่า MySQL

บน“ node1”:

# mv /etc/my.cnf /etc/my.cnf.orig

[root@node2 ~]# yum ติดตั้ง mariadb mariadb-server

ขั้นตอนที่ 14: ติดตั้งและกำหนดค่าคลัสเตอร์

ติดตั้ง SIOS Protection Suite สำหรับ Linux

ติดตั้งแพ็คเกจ Witness / Quorum

ติดตั้งแพ็คเกจ EC2 Recovery Kit

ติดตั้งรหัสใบอนุญาต

เปิด LifeKeeper GUI

สร้างเส้นทางการสื่อสาร

ตรวจสอบเส้นทางการสื่อสาร

สร้างทรัพยากรคลัสเตอร์การจำลองข้อมูล (เช่น กระจกเงา)

สร้าง Virtual IP

กำหนดค่า Ping List สำหรับทรัพยากร IP

สร้างลำดับชั้นทรัพยากร MySQL

สร้างทรัพยากร EC2 เพื่อจัดการตารางเส้นทางเมื่อเกิดข้อผิดพลาด

สร้างการพึ่งพาระหว่างทรัพยากร IP และทรัพยากรฐานข้อมูล MySQL

ขั้นตอนที่ 15: ทดสอบการเชื่อมต่อคลัสเตอร์

บทเรียนใน Cloud High Availability จากภาพยนตร์

บทเรียน Disney’s Frozen II และ Cloud Migration

1 คุณไม่สามารถเข้าสู่การย้ายระบบคลาวด์ได้หากไม่ได้รับความช่วยเหลือที่เหมาะสม

2 สิ่งต่างๆจะไม่สมเหตุสมผลเมื่อคุณอายุมากขึ้นดังนั้นควรจัดทำเอกสารและทำซ้ำ

3 อย่าวิ่งเข้าไปในกองไฟ เลือกโซลูชันความพร้อมใช้งานสูงบนคลาวด์ที่เหมาะสม

4 อย่าจมปลักอยู่กับอดีต: สิ่งที่คุณนำมาในการโยกย้ายระบบคลาวด์

5 จะมีสองอาณาจักรเสมอ: ในสถานที่และในระบบคลาวด์

เหตุใดการตรวจสอบแอปพลิเคชัน AWS EC2 จึงยากมาก

วิธีการ จำกัด โซลูชันการตรวจสอบแอปพลิเคชัน EC2 ให้แคบลง

การตรวจสอบแอปพลิเคชันที่ทำงานบน Amazon EC2 ด้วย Amazon CloudWatch หรือโซลูชั่น APM อื่น ๆ

ตรวจสอบแอปพลิเคชันที่ทำงานบน Amazon EC2 โดยใช้ SIOS AppKeeper

**กำจัด * การหยุดทำงานของเว็บเซิร์ฟเวอร์ Apache ด้วย SIOS AppKeeper Monitoring**