%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

กันยายน 10, 2020	วิธีการส่งมอบความพร้อมใช้งานสูงสำหรับ SQL Server ในสภาพแวดล้อม Linux วิธีส่งมอบความพร้อมใช้งานสูงสำหรับ SQL Server ในสภาพแวดล้อม Linux หากองค์กรของคุณใช้ Microsoft SQL Server ที่มีความสำคัญทางธุรกิจบน Linux ทีมไอทีของคุณจะรู้ดีว่าการรักษาความพร้อมใช้งานประสิทธิภาพและความปลอดภัยอย่างต่อเนื่องนั้นยากเพียงใด สิ่งที่ยากอย่างยิ่งคือการทำให้มั่นใจว่ามีความพร้อมใช้งานสูงด้วยการจำลองแบบที่มีประสิทธิภาพและการเฟลโอเวอร์อัตโนมัติ การใช้ซอฟต์แวร์โอเพนซอร์สและโซลูชันคลัสเตอร์ HA SANless ที่กำหนดค่าได้ง่ายสามารถนำเสนอแนวทางการบำรุงรักษาที่ง่ายขึ้นโดยไม่ต้องเสียสละความปลอดภัยและประสิทธิภาพที่องค์กรของคุณต้องการ ตัวเลือกความพร้อมใช้งานสูงที่ จำกัด สำหรับ Linux การกระจาย Linux ส่วนใหญ่ทำให้แผนกไอทีมีทางเลือกที่ด้อยกว่าสองทางสำหรับความพร้อมใช้งานที่สูง: จ่ายเพิ่มสำหรับ SQL Server Enterprise Edition เพื่อใช้งาน Always On Availability Groups หรือพยายามทำให้การกำหนดค่า HA Linux ที่ซับซ้อนต้องทำด้วยตัวเองทำงานได้ดีซึ่งเป็นสิ่งที่สามารถพิเศษได้ ยากที่จะทำ ปัญหาในการใช้ Enterprise Edition คือมันทำลายกลยุทธ์การประหยัดต้นทุนสำหรับการใช้ระบบปฏิบัติการโอเพนซอร์สบนฮาร์ดแวร์สินค้าโภคภัณฑ์ สำหรับแอ็พพลิเคชัน SQL Server ขนาดเล็กจำนวน จำกัด อาจเป็นไปได้ที่จะปรับค่าใช้จ่ายเพิ่มเติม แต่ราคาแพงเกินไปสำหรับแอปพลิเคชันฐานข้อมูลจำนวนมากและจะไม่ทำอะไรเลยเพื่อจัดหา HA สำหรับ Linux สำหรับวัตถุประสงค์ทั่วไป การจัดเตรียม HA ในแอปพลิเคชันทั้งหมดที่ทำงานในสภาพแวดล้อม Linux สามารถทำได้โดยใช้ซอฟต์แวร์โอเพนซอร์สเช่น Pacemaker และ Corosync หรือ SUSE Linux Enterprise High Availability Extension แต่การทำให้ซอฟต์แวร์สแต็กเต็มรูปแบบทำงานได้ตามที่ต้องการจำเป็นต้องสร้าง (และทดสอบ) สคริปต์ที่กำหนดเองสำหรับแต่ละแอปพลิเคชันและสคริปต์เหล่านี้มักจะต้องได้รับการทดสอบและอัปเดตใหม่หลังจากที่มีการเปลี่ยนแปลงเล็กน้อยกับซอฟต์แวร์หรือฮาร์ดแวร์ที่ใช้ ความสามารถที่เกี่ยวข้องกับความพร้อมใช้งานที่ไม่ได้รับการสนับสนุนทั้งใน SQL Server Standard Edition และ Linux สามารถทำให้ความพยายามนี้ท้าทายมากขึ้น การค้นหาโซลูชันความพร้อมใช้งานสูงทางเลือกสำหรับ SQL Server ใน Linux เพื่อให้ HA ทั้งประหยัดต้นทุนและใช้งานง่ายคุณอาจต้องการพิจารณาสองวิธีที่แตกต่างกันสำหรับวัตถุประสงค์ทั่วไป ระบบหนึ่งกำลังใช้ระบบที่ใช้หน่วยเก็บข้อมูลซึ่งปกป้องข้อมูลโดยการจำลองแบบภายในเครือข่ายพื้นที่จัดเก็บข้อมูล (SAN) ที่ซ้ำซ้อนและยืดหยุ่น วิธีนี้ไม่เชื่อเรื่องพระเจ้าเกี่ยวกับระบบปฏิบัติการโฮสต์ แต่ต้องการให้โครงสร้างพื้นฐาน SAN ทั้งหมดต้องได้รับจากผู้จำหน่ายรายเดียวและต้องอาศัยข้อกำหนดเกี่ยวกับความล้มเหลวแยกต่างหากเพื่อให้มีความพร้อมใช้งานสูง อีกวิธีหนึ่งคือการใช้โฮสต์และเกี่ยวข้องกับการสร้างคลัสเตอร์ SANless ที่ไม่เชื่อเรื่องพระเจ้าบนอินสแตนซ์เซิร์ฟเวอร์ Linux ในฐานะโอเวอร์เลย์ HA คลัสเตอร์เหล่านี้สามารถดำเนินการได้ทั้ง LAN และ WAN ในคลาวด์ส่วนตัวสาธารณะและไฮบริด การซ้อนทับยังไม่เชื่อเรื่องพระเจ้าโดยใช้แอปพลิเคชันทำให้องค์กรต่างๆมีโซลูชัน HA แบบสากลเดียวสำหรับทุกแอปพลิเคชัน แม้ว่าวิธีนี้จะใช้ทรัพยากรโฮสต์ แต่ก็มีราคาไม่แพงนักและปรับขนาดได้ง่ายในสภาพแวดล้อม Linux ตัวเลือกคลัสเตอร์ HA SANless ส่วนใหญ่มีการรวมกันของการจำลองข้อมูลระดับบล็อกแบบเรียลไทม์การตรวจสอบแอปพลิเคชันอย่างต่อเนื่องและนโยบายการกู้คืนสำหรับความล้มเหลว / ความล้มเหลวที่กำหนดค่าได้เพื่อปกป้องแอปพลิเคชันที่มีความสำคัญทางธุรกิจทั้งหมดรวมถึงแอปพลิเคชันที่ใช้อินสแตนซ์คลัสเตอร์แบบปิดตลอดเวลาที่มีอยู่ใน Standard Edition ของ SQL Server SIOS Technology Corp. นำเสนอโซลูชันคลัสเตอร์ HA SANless ที่มีประสิทธิภาพมากขึ้นสำหรับ Linux พร้อมความสามารถขั้นสูงที่ออกแบบมาเพื่อปลดปล่อยไอทีจากความซับซ้อนและความท้าทายในชีวิตประจำวันในการสนับสนุนและเพิ่มประสิทธิภาพโครงสร้างพื้นฐานคอมพิวเตอร์ โซลูชัน SIOS Protection Suite พร้อม LifeKeeper ให้: การตรวจสอบอย่างต่อเนื่องของสแต็กแอพพลิเคชัน Linux ทั้งหมด Application-Aware Protection ที่สมบูรณ์ด้วยชุดการกู้คืนแอปพลิเคชัน (ARK) เพื่อการกู้คืนที่รวดเร็วปลอดภัยหรือการล้มเหลวของแอปพลิเคชันและฐานข้อมูลที่ซับซ้อน การตั้งค่าที่ใช้วิซาร์ดสำหรับการทำคลัสเตอร์ Linux ความยืดหยุ่นในการกำหนดค่าเช่นการใช้คลัสเตอร์หน่วยเก็บข้อมูลที่ใช้ร่วมกันแบบดั้งเดิมหรือซอฟต์แวร์เพื่อซิงโครไนซ์ที่เก็บข้อมูลภายในในการกำหนดค่าคลัสเตอร์ SANless ตัวอย่างเช่นคลัสเตอร์ SANless สามารถจัดการกับความล้มเหลวพร้อมกันสองครั้ง การทำงานพื้นฐานจะเหมือนกันใน LAN และ WAN รวมถึงคลาวด์ส่วนตัวสาธารณะและไฮบริด ในเซิร์ฟเวอร์คลัสเตอร์สองโหนดทั่วไป # 1 เริ่มแรกเป็นเซิร์ฟเวอร์หลักที่จำลองข้อมูลไปยังเซิร์ฟเวอร์ # ประสบปัญหาโดยอัตโนมัติทริกเกอร์ล้มเหลวไปยังเซิร์ฟเวอร์ # 2 ซึ่งตอนนี้กลายเป็นหลัก ในสถานการณ์เช่นนี้แผนกไอทีน่าจะเริ่มวินิจฉัยและซ่อมแซมปัญหาใดก็ตามที่ทำให้เซิร์ฟเวอร์ # 1 ล้มเหลว เมื่อแก้ไขแล้วอาจรับช่วงต่อเนื่องจากเซิร์ฟเวอร์หลักหรือเซิร์ฟเวอร์ # 2 สามารถดำเนินการต่อในความสามารถนั้นในการจำลองข้อมูลไปยังเซิร์ฟเวอร์ # 1 ด้วยการกำหนดค่าการทำคลัสเตอร์แบบ HA SANless ส่วนใหญ่การเฟลโอเวอร์จะเป็นไปโดยอัตโนมัติและทั้งเฟลโอเวอร์และเฟลแบ็คสามารถควบคุมได้โดยคอนโซลที่ใช้เบราว์เซอร์ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับโซลูชัน SIOS LifeKeeper และ Protection Suite โปรดไปที่ SIOS SAN และ SANless High Availability Clusters สำหรับสภาพแวดล้อมของเซิร์ฟเวอร์คลัสเตอร์ ทำซ้ำโดยได้รับอนุญาตจาก SIOS
กันยายน 6, 2020	วิธีเปิดใช้งานใบอนุญาตสำหรับซอฟต์แวร์ SIOS Clustering วิธีเปิดใช้งานใบอนุญาตสำหรับซอฟต์แวร์ SIOS Clustering วิดีโอสั้น ๆ นี้เป็นครั้งแรกในชุดบทแนะนำ "วิธีการ" ที่พร้อมใช้งานของแอปพลิเคชันที่ออกแบบโดยทีมสนับสนุน SIOS โดยจะอธิบายถึงขั้นตอนง่ายๆที่จำเป็นในการเริ่มต้นใช้งาน SIOS Protection Suite หรือซอฟต์แวร์ SIOS DataKeeper เรียนรู้วิธีการเข้าถึงทรัพยากรการสนับสนุนที่หลากหลายในไลบรารีเอกสาร SIOS ทำซ้ำโดยได้รับอนุญาตจาก SIOS
สิงหาคม 30, 2020	จะเกิดอะไรขึ้นถ้าเรากำจัด Apache Downtime? *กำจัด การหยุดทำงานของเว็บเซิร์ฟเวอร์ 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 วัน * จากข้อมูลลูกค้า AppKeeper ระบุ 85% ของความล้มเหลวของบริการแอปพลิเคชัน ดังนั้นในเกือบเก้าครั้งในสิบ AppKeeper จะส่งอีเมลแจ้งให้ลูกค้าทราบว่าระบบตรวจพบการหยุดทำงานและบริการเริ่มต้นใหม่หรือรีบูตอินสแตนซ์โดยอัตโนมัติ ไม่ดีไปกว่าการตื่นตระหนกและขุดดูไฟล์บันทึกก่อนที่จะรีสตาร์ททุกอย่างด้วยตนเองใช่หรือไม่ ดูโพสต์ที่เกี่ยวข้อง: เหตุใดการตรวจสอบแอปพลิเคชัน AWS EC2 จึงยากมาก ทำซ้ำโดยได้รับอนุญาตจาก SIOS
สิงหาคม 25, 2020	เคล็ดลับในการกู้คืน SIOS Protection Suite สำหรับ Linux Configuration Specifics เคล็ดลับในการกู้คืน 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.* -rw-r – r–. 1 รูท 31312 6 พฤษภาคม 03:00 /opt/LifeKeeper/config/auto-backup.3.tgz -rw-r – r–. 1 รูท 31310 7 พฤษภาคม 03:00 /opt/LifeKeeper/config/auto-backup.4.tgz -rw-r – r–. 1 รูท 31284 8 พฤษภาคม 03:00 /opt/LifeKeeper/config/auto-backup.5.tgz -rw-r – r–. 1 รูท 31290 9 พฤษภาคม 03:00 /opt/LifeKeeper/config/auto-backup.6.tgz -rw-r – r–. 1 รูท 31291 10 พฤษภาคม 03:00 /opt/LifeKeeper/config/auto-backup.7.tgz -rw-r – r–. 1 รูท 31295 11 พฤษภาคม 03:00 /opt/LifeKeeper/config/auto-backup.8.tgz -rw-r – r–. 1 รูท 31280 12 พฤษภาคม 03:00 /opt/LifeKeeper/config/auto-backup.9.tgz -rw-r – r–. 1 รูท 31333 พ.ค. 56 03:00 /opt/LifeKeeper/config/auto-backup.0.tgz -rw-r – r–. 1 รูท 31325 14 พ.ค. 03:00 /opt/LifeKeeper/config/auto-backup.1.tgz -rw-r – r–. 1 รูท 31359 15 พฤษภาคม 03:00 /opt/LifeKeeper/config/auto-backup.2.tgz ตัวอย่าง. เอาต์พุตจากรายการ 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
สิงหาคม 18, 2020	ทีละขั้นตอน: วิธีกำหนดค่าคลัสเตอร์ล้มเหลว SANless MySQL Linux ใน Amazon EC2 ทีละขั้นตอน: วิธีกำหนดค่าคลัสเตอร์ล้มเหลว 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 เพื่อจัดการตารางเส้นทางเมื่อเกิดข้อผิดพลาด SPS-Linux มีคุณลักษณะเฉพาะที่อนุญาตให้รีซอร์สล้มเหลวระหว่างโหนดในโซนความพร้อมใช้งานและภูมิภาคต่างๆ ที่นี่ EC2 Recovery Kit (เช่นคลัสเตอร์เอเจนต์) ถูกใช้เพื่อจัดการตารางเส้นทางเพื่อให้การเชื่อมต่อกับ IP เสมือนถูกส่งไปยังโหนดคลัสเตอร์ที่ใช้งานอยู่ ในการสร้างคลิกไอคอน "บวกสีเขียว" เพื่อสร้างทรัพยากรใหม่: ทำตามวิซาร์ดเพื่อสร้างรีซอร์ส 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