SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

Archives for กุมภาพันธ์ 2021

วิธีแก้ไขปัญหาความพร้อมใช้งานของแอปพลิเคชันที่สืบทอดมา

by Leave a Comment

 

 

วิธีแก้ไขปัญหาความพร้อมใช้งานของแอปพลิเคชันที่สืบทอดมา

จะทำอย่างไรเมื่อคุณได้รับความยุ่งเหยิง

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

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

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

I. การวิจัย

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

  1. เจ้าของเดิม. ค้นคว้าเจ้าของก่อนหน้าของการกำหนดค่ารวมถึงสายการบังคับบัญชาการเข้าถึงอำนาจภูมิหลังพลวัตของทีมและกฎบัตรหากเป็นไปได้ค้นหาว่าโครงสร้างองค์กรดั้งเดิมคืออะไร
  2. ค้นคว้าสิ่งที่ทำในอดีตเพื่อให้ได้ความพร้อมใช้งานสูงหรือสูงกว่าและสิ่งที่เหลืออยู่ในบางสภาพแวดล้อมการมุ่งเน้นสำหรับความพร้อมใช้งานสูงจะตกอยู่ที่ส่วนหนึ่งของโครงสร้างพื้นฐานในขณะที่ละเลยขั้นตอนการทำงานที่ใหญ่ขึ้น เจาะลึกข้อกำหนดที่มีอยู่ ตลอดจนการเปลี่ยนแปลงใดที่ถูกนำไปใช้หรือเพิ่มเติมเนื่องจากข้อกำหนดได้รับการปลูกฝังมาตั้งแต่แรกหากคุณอยู่ระหว่างการย้ายข้อมูลบนคลาวด์โปรดเข้าใจเป้าหมายของการย้ายสภาพแวดล้อมนี้ไปยังระบบคลาวด์
  3. เจ้าของและข้อกำหนดให้ประวัติมากมาย อย่างไรก็ตามคุณยังต้องการหาข้อมูลว่าเหตุใดผู้มีอำนาจตัดสินใจสำคัญจึงตัดสินใจเลือกและแลกเปลี่ยนการออกแบบและโซลูชันตลอดจนข้อกำหนดสถาปัตยกรรมซอฟต์แวร์และฮาร์ดแวร์ประเมินว่าทางเลือกเหล่านี้ประสบความสำเร็จหรือไม่สำเร็จ การวิจัยของคุณควรมุ่งเน้นไปที่ปัญหาดั้งเดิมและแนวทางแก้ไขที่เสนอ
  4. คุณอาจต้องการพิจารณาว่าเหตุใดสภาพแวดล้อมที่คุณสืบทอดมาจึงรู้สึกเหมือนเป็นระเบียบตัวอย่างเช่นเกิดจากการขาดเอกสารการฝึกอบรมรายละเอียดการออกแบบที่ไม่ดีหรือขาดหายไปไม่มีหนังสือวิ่งหรือรายละเอียดข้อกำหนดอื่น ๆ
  5. ค้นคว้าว่ามีการใช้โซลูชันซอฟต์แวร์ความพร้อมใช้งานระดับสูงระดับองค์กรเพื่อเสริมสถาปัตยกรรมของเครื่องเสมือนเครือข่ายและแอปพลิเคชันใดบ้างหากมี มีผู้ดำรงตำแหน่งปัจจุบันหรือไม่?ถ้าไม่ก่อนหน้านี้มีวิธีการใดบ้างสำหรับความพร้อมใช้งาน?

II. พระราชบัญญัติ

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

  1. อัพเกรด

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

  2. ทำให้ดีขึ้น

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

  3. ดำเนินการ

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

  4. แทนที่

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

ในฐานะรองประธานฝ่ายประสบการณ์ลูกค้าสำหรับเทคโนโลยี SIOS ฉันประสบกับสถานการณ์ที่แสดงให้เห็นถึงความสำคัญของขั้นตอนเหล่านี้ – เมื่อทีมบริการของเราร่วมมือกับพันธมิตรระดับองค์กรเพื่อปรับใช้ผลิตภัณฑ์ SIOS Protection Suiteในขณะที่เราทำงานร่วมกันกับลูกค้าทำการวิจัยเราได้ค้นพบประวัติศาสตร์มากมาย ลูกค้ายอมรับว่ามีปัญหาการหยุดทำงานหรือความพร้อมใช้งานในจำนวน จำกัด แต่งานวิจัยของเราเปิดเผยลำดับชั้นของการแจ้งเตือนที่ไม่ยั่งยืนและซับซ้อนสูงสคริปต์ที่ดำเนินการด้วยตนเองทีมงานทั่วโลกและการผสมผสานของเครื่องมือที่รวมเข้าด้วยกัน เราสามารถประสบความสำเร็จในการออกแบบและแทนที่โซลูชันโฮมเมดของพวกเขาด้วยโซลูชันอัตโนมัติที่หรูหรากว่ามากด้วยข้อมูลนี้ ส่วนที่ดีที่สุดคือตัวช่วยสร้างซึ่งรวมถึงการตรวจสอบอัตโนมัติการกู้คืนและการป้องกันความล้มเหลวของระบบ ไม่มีกากตะกอนอีกต่อไป ไม่มี DIY แบบลองผิดลองถูกอีกต่อไป แอปพลิเคชันที่เรียบง่ายเชื่อถือได้และเฟลแบ็คสำหรับการป้องกัน HA / DR

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

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

ผลิตซ้ำจาก SIOS

คู่มือเริ่มต้นใช้งานฉบับย่อสำหรับความพร้อมใช้งานสูงสำหรับ SQL Server โดยใช้ SIOS Protection Suite สำหรับ Linux

by Leave a Comment

 

คู่มือเริ่มต้นใช้งานฉบับย่อสำหรับความพร้อมใช้งานสูงสำหรับ SQL Server โดยใช้ SIOS Protection Suite สำหรับ Linux

คู่มือนี้จัดทำขึ้นเพื่อแสดงการป้องกัน Microsoft SQL Server โดยใช้ SIOS Protection Suite สำหรับ Linux สภาพแวดล้อมที่ใช้ที่นี่คือ VMware ESXi พร้อมเครื่องเสมือนที่เพิ่มการรัน CentOS 7.6 กำลังใช้ Microsoft SQL 2017 เพื่อสร้างเซิร์ฟเวอร์ฐานข้อมูล บันทึกฐานข้อมูลและธุรกรรมจะถูกจัดเก็บไว้ในดิสก์ภายในเครื่องซึ่งจะถูกจำลองแบบระหว่างโหนดโดยใช้ DataKeeper ซึ่งแสดงให้เห็นว่าพื้นที่เก็บข้อมูลที่ใช้ร่วมกันสามารถใช้แทนดิสก์ภายในเครื่อง

คู่มือนี้มีให้ที่นี่ในรูปแบบ pdf

ดาวน์โหลดซอฟต์แวร์ Microsoft ที่จำเป็น

  1. เปิดคู่มือ Microsoft ต่อไปนี้สำหรับการติดตั้ง SQL ที่ https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-setup?view=sql-server-ver15

วางแผนการกำหนดค่าสภาพแวดล้อม SQL

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

การกำหนดค่าทั่วไป

  1. ตัวอย่างที่เราติดตั้งในคู่มือเริ่มต้นใช้งานฉบับย่อนี้ใช้ CentOS คำแนะนำของ Red Hat ใช้เนื่องจาก CentOS เป็นไบนารีที่เข้ากันได้กับ Red Hat
  2. ตัวอย่างในคู่มือเริ่มใช้งานฉบับย่อนี้จะคล้ายกันมากไม่ว่าจะทำงานในสภาพแวดล้อม VMware ระบบคลาวด์หรือการติดตั้งทางกายภาพ

การกำหนดค่าโหนด 1

  • ชื่อโฮสต์: IMAMSSQL-1
  • IP สาธารณะ: 192.168.4.21
  • IP ส่วนตัว: 10.1.4.21
  • / dev / sdb (10GiB)
  • / dev / sdc (10GiB)

การกำหนดค่าโหนด 2

  • ชื่อโฮสต์: IMAMSSQL-2
  • IP สาธารณะ: 192.168.4.22
  • IP ส่วนตัว: 10.1.4.22
  • / dev / sdb (10GiB)
  • / dev / sdc (10GiB)

Virtual IP ที่ใช้สำหรับ SQL Access

  • 168.4.20 ซึ่งจะได้รับการปกป้องโดย LifeKeeper และ "ลอย" ระหว่างโหนด

ระบบปฏิบัติการ

  • CentOS 7.6.2

การกำหนดค่าฐานข้อมูล SQL

  • ฐานข้อมูล SQL:
  • ชื่อโฮสต์เสมือนของ SQL: IMAMSSQL
  • IP เสมือนของ SQL: 192.168.4.20

จุดติดตั้งระบบไฟล์ SQL

  • / ฐานข้อมูล / ข้อมูล
  • / database / xlog

เตรียมระบบสำหรับการติดตั้ง

การติดตั้ง MS-SQL

การติดตั้ง SQL เริ่มต้น

ในส่วนนี้เราจะเพิ่มตำแหน่งแพคเกจของ Microsoft ลงใน Linux OS ของเราจากนั้นสั่งให้ OS ติดตั้ง SQL Server

  1. เปิดคู่มือ Microsoft ต่อไปนี้เพื่อติดตั้ง SQL Server:
    https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-setup?view=sql-server-ver15
  2. เข้าสู่ระบบด้วยสิทธิ์ root หรือคุณใช้ sudo ก่อนแต่ละคำสั่ง
  3. curl -o /etc/yum.repos.d/mssql-server.repo https://packages.microsoft.com/config/rhel/7/mssql-server-2017.repo
  4. yum ติดตั้ง -y mssql-server
  5. / opt / mssql / bin / mssql-conf setup ฉันติดตั้ง SQL Server ด้วยใบอนุญาตการประเมินผล
  6. ติดตั้ง yum -y mssql-tools unixODBC-devel
  7. echo 'export PATH =” $ PATH: / opt / mssql-tools / bin”‘ >> ~ / .bash_profile
  8. echo 'export PATH =” $ PATH: / opt / mssql-tools / bin”‘ >> ~ / .bashrc
  9. ที่มา ~ / .bashrc
  10. systemctl หยุด mssql-server.service เราหยุดบริการ SQL และไม่สามารถเริ่มบริการ SQL ได้จนกว่าเราจะกำหนดค่าดิสก์ที่ใช้เป็นที่เก็บข้อมูลในส่วนที่ชื่อว่า
    “ สร้างฐานข้อมูลและระบบล็อกไฟล์ธุรกรรมและจุดเชื่อมต่    อ”
  11. / opt / mssql / bin / mssql-conf ตั้งค่า filelocation.masterdatafile /database/data/master.mdf
  12. / opt / mssql / bin / mssql-conf ตั้งค่า filelocation.masterlogfile /database/xlog/mastlog.ldf

สร้างฐานข้อมูลและระบบล็อกไฟล์ธุรกรรมและจุดเชื่อมต่อ

เราจะใช้ประเภทระบบไฟล์ xfs สำหรับการติดตั้งนี้ อ้างถึงประเภทระบบไฟล์ที่ LifeKeeper รองรับเพื่อกำหนดระบบไฟล์ที่คุณต้องการกำหนดค่า ตรวจสอบให้แน่ใจว่าคุณกำหนดค่าดิสก์เพื่อใช้ตัวระบุ GUID ที่นี่เราจะแบ่งพาร์ติชันและจัดรูปแบบดิสก์ที่แนบมาในเครื่อง ติดตั้งสร้างและอนุญาตตำแหน่งฐานข้อมูลที่เราต้องการให้ SQL ใช้ในที่สุดเราจะเริ่ม SQL ซึ่งจะสร้าง Master DB ใหม่และบันทึกธุรกรรมในตำแหน่งที่เราระบุ หมายเหตุเมื่อสร้างพาร์ติชัน DataKeeper กำหนดให้จำนวนบล็อกในพาร์ติชันเป็นเลขคี่ เช่น. 20973567 (จบ) – 2048 (เริ่ม) = 20971519.

  1. fdisk / dev / sdb
  2. mkfs -t xfs / dev / sdb1
  3. fdisk / dev / sdc
  4. mkfs -t xfs / dev / sdc1
  5. mkdir / ฐานข้อมูล; mkdir / ฐานข้อมูล / ข้อมูล; mkdir / ฐานข้อมูล / xlog
  6. chown mssql / ฐานข้อมูล /; chgrp mssql / ฐานข้อมูล /
  7. chown mssql / ฐานข้อมูล / ข้อมูล /; chgrp mssql / ฐานข้อมูล / ข้อมูล /
  8. chown mssql / ฐานข้อมูล / xlog /; chgrp mssql / ฐานข้อมูล / xlog /
  9. vi / etc / fstab
    1. เพิ่ม / dev / sdb1 ติดตั้งกับ / database / data เช่น / dev / sdb1 / database / data xfs ค่าเริ่มต้น 0 0
    2. เพิ่ม / dev / sdb1 การติดตั้งไปยัง / database / xlog เช่น / dev / sdb1 / database / xlog xfs ค่าเริ่มต้น 0 0
  10. เมานต์ / dev / sdb1
  11. เมานต์ / dev / sdc1
  12. chown mssql / ฐานข้อมูล / ข้อมูล /; chgrp mssql / ฐานข้อมูล / ข้อมูล /
  13. chown mssql / ฐานข้อมูล / xlog /; chgrp mssql / ฐานข้อมูล / xlog /
  14. systemctl เริ่มต้น mssql-server.service เราเริ่มบริการ SQL ทันทีที่เมาท์ดิสก์ในเครื่องซึ่งจะสร้างฐานข้อมูลหลักและบันทึกธุรกรรมใหม่

การติดตั้ง LifeKeeper

โปรดดูคู่มือการติดตั้ง
http://docs.us.sios.com/spslinux/9.5.1/en/topic/sios-protection-suite-for-linux-installation-guide

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

เปิด LifeKeeper GUI บนโหนดหลัก:

# / opt / LifeKeeper / bin / lkGUIapp &

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

สร้างแบ็กเอนด์และ / หรือเส้นทาง IP ส่วนหน้าในกรณีแบ็กเอนด์ของเราคือ 10.2.4.21 & 22 และส่วนหน้าคือ 192.168.4.21 & 22

  1. [AWS only] คลิกขวาที่แต่ละอินสแตนซ์ใน AWS Management Console และเลือก Networking → Change Source / Dest ตรวจสอบและตรวจสอบให้แน่ใจว่าการตรวจสอบต้นทาง / ปลายทางถูกปิดใช้งาน
  2. ใน LifeKeeper GUI คลิก Create Comm Path
  3. ในไดอะล็อกเซิร์ฟเวอร์ระยะไกลให้เพิ่มชื่อโฮสต์ของโหนดคลัสเตอร์อื่นแล้วเลือก

 

  1. เลือกที่อยู่ IP ในเครื่อง (10.2.4.21) และรีโมต (10.2.4.22) ที่เหมาะสม
  2. ทำซ้ำขั้นตอนนี้โดยสร้างเส้นทางการสื่อสารระหว่างคู่ของโหนดระยะไกลทั้งหมดสำหรับแต่ละเครือข่าย (เช่น 12.0.1.30 และ 12.0.2.30)หลังจากเสร็จสิ้นเส้นทางการสื่อสารควรมีอยู่ระหว่างคู่ทั้งหมดของโหนดคลัสเตอร์

ทรัพยากร IP

ทรัพยากร IP คือ IP เสมือนที่จะใช้ในการเข้าถึงเซิร์ฟเวอร์ SQL – ในกรณีนี้คือ 192.168.4.20

  1. ตรวจสอบว่า IP เสมือนทั้งหมดถูกลบออกจากอินเทอร์เฟซเครือข่ายแล้วโดยการเรียกใช้
    "ip addr show"
  2. สร้างทรัพยากร IP สำหรับ IP เสมือน MSSQL
  3. ใน LifeKeeper GUI ให้คลิก Create Resource Hierarchy และเลือก IP

4. เมื่อได้รับแจ้งให้ป้อน IP 192.168.4.20 และเลือกซับเน็ตมาสก์ 255.255.0.0

5. ป้อนชื่อแท็กเช่น ip-192.168.4.20-MSSQL

ทรัพยากร DataKeeper

นี่คือไดรฟ์ที่ใช้ในการจัดเก็บฐานข้อมูลและบันทึกธุรกรรม / database / data และ / database / xlog

ทรัพยากรการจำลองข้อมูล

  1. ตรวจสอบให้แน่ใจว่าระบบไฟล์ SQL ทั้งหมดถูกเมาท์ที่จุดเชื่อมต่อที่เหมาะสมภายใต้ / ฐานข้อมูลบนโหนดคลัสเตอร์หลัก
    # เมานต์
    …
    / dev / sdb1 บน / ฐานข้อมูล / ชนิดข้อมูล xfs (rw, relatime, attr2, inode64, noquota)

/ dev / sdc1 บน / database / xlog ประเภท xfs (rw, relatime, attr2, inode64, noquota)
…

2. ตรวจสอบให้แน่ใจว่าระบบไฟล์ไม่ได้ติดตั้งบนโหนดคลัสเตอร์สำรอง

3.ใน LifeKeeper GUI คลิก Create Resource Hierarchy และเลือก Data Replication

4. สำหรับ Hierarchy Type เลือก Replicate Existing Filesystem

5. สำหรับ Mount Point ที่มีอยู่ให้เลือก / database / data

6. เลือกค่าที่เหมาะสมสำหรับส่วนที่เหลือของกล่องโต้ตอบการสร้างตามความเหมาะสมสำหรับสภาพแวดล้อมของคุณ

ทำซ้ำขั้นตอนที่ 3-6 สำหรับระบบไฟล์ / database / data และ / database / xlog

การป้องกันบริการด่วน

เราจะใช้ ARK การป้องกันบริการด่วนของ LifeKeeper เพื่อปกป้องบริการเซิร์ฟเวอร์ mssql ซึ่งจะตรวจสอบบริการ MSSQL และตรวจสอบให้แน่ใจว่าทำงานอยู่

  1. ใช้สถานะ systemctl mssql-server.service บนโหนด 1 เพื่อให้แน่ใจว่า MSSQL กำลังทำงานอยู่
  2. ใช้สถานะ systemctl mssql-server.service บนโหนด 2 เพื่อให้แน่ใจว่า MSSQL ไม่ทำงานหากเป็นเช่นนั้นคุณจะต้องหยุดบริการโดยใช้ systemctl stop mssql-server.service จากนั้นยกเลิกการต่อเชื่อม / database / data และ / database / xlog ไดเร็กทอรี
  3. ใน LifeKeeper GUI ให้คลิกเพิ่มทรัพยากร
  4. เลือก QSP ARK จากเมนูแบบเลื่อนลง
  5. เมื่อเติมรายการบริการที่มีให้เลือก mssql-server.service
  6. เลือกค่าที่เหมาะสมสำหรับส่วนที่เหลือของกล่องโต้ตอบการสร้างตามความเหมาะสมกับสภาพแวดล้อมของคุณ
  7. ขยายลำดับชั้นไปที่โหนด 2
  8. ที่ linux CLI บนโหนด 1 ให้เรียกใช้“ / opt / LifeKeeper / bin / lkpolicy -g –v” ผลลัพธ์จะมีลักษณะดังนี้:
  9. หาก LocalRecovery: On ถูกตั้งค่าสำหรับ QSP-mssql-server เราจำเป็นต้องปิดการใช้งานการกู้คืนภายในทั้งสองโหนดซึ่งทำได้โดยการดำเนินการ (บนทั้งสองโหนด)
  10. / opt / LifeKeeper / bin / lkpolicy -s LocalRecovery -E tag =” QSP-mssql-server”
  11. ยืนยันว่าการกู้คืนภายในเครื่องถูกปิดใช้งานบนทั้งสองโหนด“ / opt / LifeKeeper / bin / lkpolicy -g –v”:

ผลิตซ้ำจาก SIOS

เวอร์ชัน 8.7.2 SIOS Protection Suite-Windows และ DataKeeper Cluster Edition

by Leave a Comment

ประกาศเวอร์ชัน 8.7.2 ของ SIOS Protection Suite-Windows และ DataKeeper Cluster Edition

เรายินดีที่จะประกาศการเปิดตัว SIOS Protection Suite สำหรับ Windows เวอร์ชัน 8.7.2 รวมถึง DataKeeper Cluster Editionรุ่นใหม่มีคุณสมบัติดังต่อไปนี้:

ใหม่ Oracle Pluggable Databases (PDB) Application Recovery Kit

  • ขอแนะนำให้ใช้ Oracle Pluggable Database บน Oracle 19c และจำเป็นบน Oracle 20c เป็นต้นไป
  • ไม่จำเป็นต้องมีใบอนุญาต SIOS เพิ่มเติมสำหรับชุดการกู้คืนแอปพลิเคชัน SIOS Protection Suite PDB แต่ต้องใช้ทรัพยากร Oracle ที่มีอยู่

รองรับแพลตฟอร์มและระบบปฏิบัติการเพิ่มเติม ได้แก่ Azure Stack (Hub) (เพื่อรวม Windows Server 2019), vSphere 7 และ PostgreSQL 12 สำหรับรายการผลิตภัณฑ์ที่รองรับทั้งหมดของเราโปรดไปที่ SIOS Protection Suite – เมทริกซ์การสนับสนุน Windows 8.7.2

ผลิตซ้ำจาก SIOS

เกี่ยวกับการใช้ Amazon FSX สำหรับ SQL Server Failover Cluster Instance

by Leave a Comment

เกี่ยวกับการใช้ Amazon FSX สำหรับ SQL Server Failover Cluster Instance

การใช้ Amazon FSX สำหรับอินสแตนซ์คลัสเตอร์ล้มเหลวของเซิร์ฟเวอร์ SQL – สิ่งที่คุณต้องรู้!

หากคุณกำลังพิจารณาปรับใช้อินสแตนซ์ Microsoft SQL Server ของคุณเองใน AWS EC2 คุณมีการตัดสินใจบางอย่างเกี่ยวกับความยืดหยุ่นของโซลูชัน แน่นอนว่า AWS จะเสนอ SLA 99.99% ให้กับทรัพยากรการประมวลผลของคุณหากคุณปรับใช้สองอินสแตนซ์ขึ้นไปในโซนความพร้อมใช้งานที่แตกต่างกัน แต่อย่าเพิ่งหลงเชื่อมีปัจจัยอื่น ๆ อีกมากมายที่คุณต้องพิจารณาเมื่อคำนวณความพร้อมใช้งานของแอปพลิเคชันที่แท้จริง ฉันเพิ่งเขียนบล็อกเกี่ยวกับวิธีคำนวณความพร้อมใช้งานแอปพลิเคชันของคุณในระบบคลาวด์ คุณควรอ่านบทความนั้นอย่างรวดเร็วก่อนที่จะดำเนินการต่อ

เมื่อพูดถึงการตรวจสอบให้แน่ใจว่าอินสแตนซ์ Microsoft SQL Server ของคุณพร้อมใช้งานสูงจริงๆแล้วจะมีตัวเลือกพื้นฐานสองตัวเลือก: Always On Availability Group (AG) หรือ SQL Server Failover Cluster Instance (FCI) หากคุณกำลังอ่านบทความนี้ฉันตั้งสมมติฐานว่าคุณทราบดีถึงตัวเลือกทั้งสองนี้และกำลังพิจารณาอย่างจริงจังที่จะใช้อินสแตนซ์คลัสเตอร์ล้มเหลวของเซิร์ฟเวอร์ SQL แทน SQL Server Always On AG

ประโยชน์ของอินสแตนซ์คลัสเตอร์ล้มเหลวของเซิร์ฟเวอร์ SQL ของ Microsoft

รายการต่อไปนี้สรุปสิ่งที่ AWS กล่าวว่าเป็นประโยชน์ของ SQL Server FCI:

โดยทั่วไปแล้ว FCI เป็นที่ต้องการมากกว่า AG สำหรับการปรับใช้ SQL Server ที่มีความพร้อมใช้งานสูงเมื่อสิ่งต่อไปนี้เป็นข้อกังวลลำดับความสำคัญสำหรับกรณีการใช้งานของคุณ:

ประสิทธิภาพต้นทุนใบอนุญาต: คุณต้องมีสิทธิ์การใช้งาน Enterprise Edition ของ SQL Server เพื่อเรียกใช้ AGs ในขณะที่คุณต้องการเพียงสิทธิ์การใช้งาน Standard Edition เพื่อเรียกใช้ FCI โดยทั่วไปแล้วราคาถูกกว่า Enterprise Edition 50–60% แม้ว่าคุณจะสามารถเรียกใช้ AG รุ่นพื้นฐานบน Standard Edition ได้โดยเริ่มจาก SQL Server 2016 แต่ก็มีข้อ จำกัด ในการรองรับฐานข้อมูลเพียงฐานข้อมูลเดียวต่อ AG สิ่งนี้อาจกลายเป็นความท้าทายเมื่อต้องจัดการกับแอปพลิเคชันที่ต้องใช้ฐานข้อมูลหลายฐานข้อมูลเช่น SharePoint

การป้องกันระดับอินสแตนซ์เทียบกับการป้องกันระดับฐานข้อมูล: ด้วย FCI อินสแตนซ์ทั้งหมดจะได้รับการป้องกัน – หากโหนดหลักไม่พร้อมใช้งานอินสแตนซ์ทั้งหมดจะถูกย้ายไปยังโหนดสแตนด์บาย สิ่งนี้จะดูแลการล็อกอินของ SQL Server งาน SQL Server Agent ใบรับรอง ฯลฯ ที่เก็บไว้ในฐานข้อมูลระบบซึ่งจัดเก็บทางกายภาพในที่เก็บข้อมูลแบบแบ่งใช้ ในทางกลับกันด้วย AG ในทางกลับกันเฉพาะฐานข้อมูลในกลุ่มเท่านั้นที่ได้รับการปกป้องและไม่สามารถเพิ่มฐานข้อมูลระบบลงใน AG ได้ – อนุญาตให้ใช้เฉพาะฐานข้อมูลผู้ใช้เท่านั้น เป็นความรับผิดชอบของผู้ดูแลระบบฐานข้อมูลในการทำซ้ำการเปลี่ยนแปลงอ็อบเจ็กต์ระบบในการจำลอง AG ทั้งหมด สิ่งนี้ทำให้ความเป็นไปได้ที่จะเกิดข้อผิดพลาดของมนุษย์ซึ่งทำให้ฐานข้อมูลไม่สามารถเข้าถึงแอปพลิเคชันได้

การสนับสนุนคุณลักษณะ DTC: หากคุณใช้ SQL Server 2012 หรือ 2014 และแอปพลิเคชันของคุณใช้ Distributed Transaction Coordinator (DTC) คุณจะไม่สามารถใช้ AG ได้เนื่องจากไม่ได้รับการสนับสนุน ใช้ FCI ในสถานการณ์นี้

https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/

ความท้าทายกับ FCI ในคลาวด์

แน่นอน. ความท้าทายในการสร้าง FCI ที่ครอบคลุมโซนความพร้อมใช้งานคือการขาดอุปกรณ์จัดเก็บข้อมูลที่ใช้ร่วมกันซึ่งโดยปกติจำเป็นต้องใช้ เนื่องจากโหนดของคลัสเตอร์ถูกกระจายไปตามศูนย์ข้อมูลหลายแห่ง SAN แบบดั้งเดิมจึงไม่ใช่ตัวเลือกที่ใช้ได้สำหรับพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน นั่นทำให้เรามีทางเลือกสองทางสำหรับการจัดเก็บคลัสเตอร์: ทรัพยากรระดับพื้นที่เก็บข้อมูลของบุคคลที่สามเช่น SIOS DataKeeper หรือ Amazon FSx ใหม่

มาดูสิ่งที่คุณต้องรู้ก่อนตัดสินใจเลือก

ข้อตกลงระดับการให้บริการ

ตามที่ฉันเขียนไว้ในวิธีคำนวณความพร้อมใช้งานแอปพลิเคชันของคุณ SLA แอปพลิเคชันโดยรวมของคุณนั้นดีพอ ๆ กับลิงก์ที่อ่อนแอที่สุดของคุณ ในกรณีนี้ FSx SLA 99.9%

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

ในกรณีที่คุณไม่ทราบความแตกต่างระหว่างสามเก้ากับสี่เก้า …

  • ความพร้อมใช้งาน 99.9% ช่วยให้หยุดทำงานได้ 43.83 นาทีต่อเดือน
  • ความพร้อมใช้งาน 99.99% ช่วยให้หยุดทำงานได้เพียง 4.38 นาทีต่อเดือน

ด้วยการโฮสต์พื้นที่จัดเก็บคลัสเตอร์ของคุณบน FSx แม้ว่าคุณจะมีความพร้อมในการประมวลผล 99.99% ความพร้อมใช้งานแอปพลิเคชันโดยรวมของคุณจะเป็น 99.9% ในทางตรงกันข้ามไดรฟ์ข้อมูล EBS ที่ครอบคลุมโซนความพร้อมใช้งานเช่นในการปรับใช้ DataKeeper จะมีคุณสมบัติสำหรับ SLA 99.99% ทั้งในชั้นพื้นที่จัดเก็บข้อมูลและการประมวลผล ซึ่งหมายความว่าความพร้อมใช้งานโดยรวมของคุณคือ 99.99%

สถานที่จัดเก็บ

เมื่อกำหนดค่า FSx เพื่อความพร้อมใช้งานสูงคุณจะต้องเปิดใช้งานการสนับสนุนหลาย AZ การเปิดใช้งานหลาย AZ จะทำให้คุณมี AZ ที่ "ต้องการ" และ AZ "สแตนด์บาย" ได้อย่างมีประสิทธิภาพ เมื่อคุณปรับใช้โหนด SQL Server FCI ของคุณคุณจะต้องการกระจายโหนดเหล่านั้นใน AZ เดียวกัน

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

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

หากไม่จับตาดูสถานะ FSx และ SQL Server FCI ของคุณอย่างใกล้ชิดคุณอาจไม่รู้ด้วยซ้ำว่ากำลังทำงานอยู่ในภูมิภาคต่างๆจนกว่าคุณจะเห็นค่าธรรมเนียมการถ่ายโอนข้อมูลเมื่อสิ้นเดือน

ในทางตรงกันข้ามในคอนฟิกูเรชันที่ใช้ SIOS DataKeeper การล้มเหลวของหน่วยเก็บข้อมูลเป็นส่วนหนึ่งของการกู้คืน SQL Server FCI เพื่อให้แน่ใจว่าที่เก็บข้อมูลมักจะล้มเหลวด้วยอินสแตนซ์ SQL Server สิ่งนี้ทำให้มั่นใจได้ว่า SQL Server จะอ่านและเขียนไปยังไดรฟ์ข้อมูล EBS ที่เชื่อมต่อโดยตรงกับโหนดที่ใช้งานอยู่ โปรดทราบว่า DataKeeper จะต้องเสียค่าใช้จ่ายในการถ่ายโอนข้อมูลที่เกี่ยวข้องกับการดำเนินการเขียนซึ่งจำลองแบบระหว่าง AZ หรือภูมิภาค ต้นทุนการถ่ายโอนข้อมูลนี้สามารถลดลงได้ด้วยการใช้การบีบอัดที่มีอยู่ใน DataKeeper

การควบคุมล้มเหลว

ในคอนฟิกูเรชันหลายซับเน็ต FSx มีโซนความพร้อมใช้งานที่ต้องการและความพร้อมใช้งานสแตนด์บาย หากไฟล์เซิร์ฟเวอร์ FSx ในโซนความพร้อมใช้งานที่ต้องการประสบกับความล้มเหลวเซิร์ฟเวอร์ไฟล์ใน AZ สแตนด์บายจะกู้คืน AWS รายงานว่าเวลาในการกู้คืนนี้ใช้เวลาประมาณ 30 วินาทีกับการแชร์มาตรฐาน ด้วยการใช้การแชร์ไฟล์ที่มีอยู่อย่างต่อเนื่อง Microsoft รายงานว่าเวลาเฟลโอเวอร์นี้อาจใกล้ถึง 15 วินาที ในช่วงเวลาล้มเหลวนี้จะมีไฟดับที่เกิดขึ้นเมื่อการอ่านและการเขียนหยุดชั่วคราว แต่จะดำเนินต่อไปเมื่อการกู้คืนเสร็จสมบูรณ์

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

บริการวิเคราะห์เซิร์ฟเวอร์ SQL คลัสเตอร์ไม่รองรับ FSX

หากคุณต้องการคลัสเตอร์ SSAS คุณจะต้องมีทรัพยากรดิสก์แบบคลัสเตอร์เช่น SIOS DataKeeper เอกสารไวท์เปเปอร์ How to Cluster SQL Server Analysis Server ระบุอย่างชัดเจนว่าไม่สามารถใช้ SMB ได้และต้องใช้คลัสเตอร์ไดรฟ์ที่มีอักษรระบุไดรฟ์ ในทางตรงกันข้ามทรัพยากร DataKeeper Volume จะแสดงตัวเองเป็นดิสก์คลัสเตอร์และสามารถใช้กับ SSAS ได้

สรุป

แม้ว่า FSx จะเหมาะสมกับการใช้งาน SMB ทั่วไปเช่นไฟล์ผู้ใช้ Windows และบริการอื่น ๆ ที่ไม่สำคัญซึ่ง SLA ความพร้อมใช้งาน 99.9% เพียงพอ แต่ FSx เป็นตัวเลือกที่ยอดเยี่ยมหากแอปพลิเคชันของคุณต้องการความพร้อมใช้งานสูง (99.99%) หรือโซลูชัน HA / DR ที่ครอบคลุม ภูมิภาค SIOS DataKeeper คือขนาดที่เหมาะสม

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

SIOS Protection Suite สำหรับ Linux Quick Service Protection

by Leave a Comment

วิธีเพิ่มการรองรับแอปพลิเคชันแบบกำหนดเองให้กับ SIOS Protection Suite - SIOS Protection Suite สำหรับ Linux Quick Service Protection

การใช้ SIOS Protection Suite สำหรับ Linux Quick Service Protection Resource

ในการมีส่วนร่วมกับทีม SIOS Professional Services เมื่อเร็ว ๆ นี้ลูกค้าได้สอบถามเกี่ยวกับวิธีป้องกันแอปพลิเคชันที่กำหนดเองด้วยโซลูชัน SIOS Protection Suite สำหรับ Linux หนึ่งในผู้เชี่ยวชาญด้านความพร้อมใช้งานที่มีประสบการณ์สูงที่ SIOS Technology Corp. ได้ช่วยทำความเข้าใจแอปพลิเคชันของลูกค้าและกำหนดวิธีการที่ SIOS มีให้สำหรับการสนับสนุนแอปพลิเคชันที่กำหนดเอง

SIOS Protection Suite สำหรับ Linux มีหลายวิธีในการเพิ่มความพร้อมใช้งานสูงและการตรวจสอบแอปพลิเคชันให้กับแอปพลิเคชันแบบกำหนดเองตัวเลือกเหล่านี้มีดังต่อไปนี้:

  • การสร้างชุดการกู้คืนแอปพลิเคชันแบบกำหนดเอง (ARK) 1
  • การสร้างลำดับชั้นทรัพยากรแอปพลิเคชันทั่วไป
  • การสร้างทรัพยากรการป้องกันบริการด่วน
ประเภท ความซับซ้อนของการเข้ารหัส การตรวจสอบ การกู้คืน
ทรัพยากรชุดการกู้คืนแอปพลิเคชันแบบกำหนดเอง 1 สูงสุด สูงสุด สูงสุด
ทรัพยากรแอปพลิเคชันทั่วไป ปานกลาง สูง สูง
ทรัพยากรการป้องกันบริการด่วน ต่ำ ปานกลาง ปานกลาง

คำจำกัดความที่ใช้ในแผนภูมิ

การตรวจสอบ – หมายถึงความสามารถในการกำหนดความพร้อมการเข้าถึงและการทำงานของแอปพลิเคชันฐานข้อมูลหรือบริการที่ได้รับการป้องกันการตรวจสอบแอปพลิเคชันฐานข้อมูลหรือบริการในระดับต่ำให้ความครอบคลุมพื้นฐานเช่นการตรวจสอบกระบวนการที่กำลังทำงานอยู่การมีอยู่ของ pid_file หรือคำสั่งสถานะจะส่งคืนผลลัพธ์เป็น "จริง" เมื่อดำเนินการหมายเหตุ: โค้ดส่งคืน "จริง" หรือ "0 (ศูนย์)" ไม่ได้หมายความว่าแอปพลิเคชันฐานข้อมูลหรือบริการกำลังทำงานอยู่ แต่มีเพียงคำสั่งที่ดำเนินการเท่านั้นที่สามารถดำเนินการได้สำเร็จด้วยผลลัพธ์สถานะบวก ("จริง" หรือ "0 (ศูนย์)")ระดับสูงสุดของการตรวจสอบบ่งชี้ว่าความรู้เฉพาะของแอปพลิเคชันถูกนำไปใช้เพื่อกำหนดความสมบูรณ์และการทำงานของแอปพลิเคชันนอกเหนือจากวิธีการระดับล่างเช่นสถานะของกระบวนการเอาต์พุต ps หรือการคืนสถานะ systemdระดับสูงสุดของการเฝ้าติดตามโดยทั่วไปจะใช้ความรู้เกี่ยวกับลำดับการดำเนินการตรวจสุขภาพที่แนะนำความรู้เกี่ยวกับการพึ่งพาและการวิเคราะห์ผลลัพธ์ที่ได้รับจากสถานะและคำสั่งการตรวจสอบ

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

วิธีแก้ไข: ทรัพยากรการป้องกันบริการด่วน

ในการมีส่วนร่วมนี้แอปพลิเคชันของลูกค้ามีความเข้ากันได้ของระบบ จากข้อกำหนดโดยรวมในการหลีกเลี่ยงการเข้ารหัสความต้องการการตรวจสอบขั้นต่ำและขั้นตอนการกู้คืนอย่างง่ายเราขอแนะนำทรัพยากร Quick Service Protection (QSP)

ทรัพยากร QSP ทำงานเพื่อเพิ่มการสนับสนุนของบริการ systemd ไปยัง SIOS Protection Suite สำหรับการปกป้องทรัพยากร Linux อย่างรวดเร็วในกรณีของ Customer Example.com พวกเขามีบริการที่เข้ากันได้กับ systemd โดยมีข้อกำหนดขั้นต่ำที่จำเป็นในการเริ่มและหยุดแอปพลิเคชัน

[Unit]

Description = SIOS 'as-is' Example Service 2020

หลังจาก = network.target

พ[Service]ิมพ์ = ง่าย

รีสตาร์ท = เสมอ

RestartSec = 3

ผู้ใช้ = root

ExecStart = / example_app / bin / exampleapp เริ่มต้น

ExecStop = / example_app / bin / exampleapp หยุด[Install]

WantedBy = multi-user.target

ไฟล์ Example.com systemd

SIOS ขอแนะนำว่าก่อนที่จะพยายามป้องกันทรัพยากรด้วยผลิตภัณฑ์ SIOS Protection Suite สำหรับ Linux ให้ตรวจสอบผ่าน systemctl ว่าแอปพลิเคชันตัวอย่างหยุดทำงานและเริ่มทำงานตามนั้น:

# systemctl ตัวอย่างสถานะ

* example.service – SIOS "ตามสภาพ" บริการตัวอย่างปี 2020

โหลดแล้ว: โหลดแล้ว (/usr/lib/systemd/system/example.service; ปิดใช้งานพรีเซ็ตผู้ขาย: ปิดใช้งาน)

ใช้งาน: ไม่ใช้งาน (ตาย)

# systemctl start ตัวอย่าง

# systemctl ตัวอย่างสถานะ

* example.service – SIOS "ตามสภาพ" บริการตัวอย่างปี 2020

โหลดแล้ว: โหลดแล้ว (/usr/lib/systemd/system/example.service; ปิดใช้งานพรีเซ็ตผู้ขาย: ปิดใช้งาน)

ใช้งาน: ใช้งานอยู่ (ทำงาน) ตั้งแต่ศ. 2020-08-21 14:53:27 EDT; 5 วินาทีที่ผ่านมา

PID หลัก: 19937 (exampleapp)

กลุ่ม CG: /system.slice/example.service

`-19937 / usr / bin / perl / example_app / bin / exampleapp เริ่มต้น

# systemctl stop ตัวอย่าง

# systemctl ตัวอย่างสถานะ

* example.service – SIOS "ตามสภาพ" บริการตัวอย่างปี 2020

โหลดแล้ว: โหลดแล้ว (/usr/lib/systemd/system/example.service; ปิดใช้งานพรีเซ็ตผู้ขาย: ปิดใช้งาน)

ใช้งานอยู่: ไม่ใช้งาน (ตาย)

หลังจากตรวจสอบว่าแอปพลิเคชันทำงานอย่างถูกต้องผ่าน systemd ให้เริ่มบริการใหม่และตรวจสอบให้แน่ใจว่าบริการกำลังทำงานอยู่

# systemctl start ตัวอย่าง

# systemctl ตัวอย่างสถานะ

* example.service – SIOS "ตามสภาพ" บริการตัวอย่างปี 2020

โหลดแล้ว: โหลดแล้ว (/usr/lib/systemd/system/example.service; ปิดใช้งานพรีเซ็ตผู้ขาย: ปิดใช้งาน)

ใช้งาน: ใช้งานอยู่ (ทำงาน) ตั้งแต่ศ. 2020-08-21 15:59:44 EDT; 3 นาที 2 วินาทีที่แล้ว

PID หลัก: 30740 (exampleapp)

โปรดดูเอกสารประกอบ SIOS Protection Suite สำหรับ Linux Quick Service Protection Suite สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับกระบวนการสร้างทรัพยากร

การใช้ SPS-L UI เลือกตัวเลือกสร้างที่ระบุใน Global UI Resource Toolbar โดยไอคอนต่อไปนี้:

เมื่อSIOS Global US Resourceเปิดตัวช่วยสร้างให้เลือกตัวเลือก Quick Service Protection ในหน้าต่าง Create Resource Wizard

ในข้อความแจ้งถัดไปสำหรับ "Switchback Type" ให้เลือกว่าคุณจะใช้การสลับกลับอัจฉริยะหรือการสลับกลับอัตโนมัติ

หลังจากเลือก "Switchback Type" กล่องโต้ตอบเซิร์ฟเวอร์จะปรากฏขึ้นเพื่อให้คุณสามารถเลือกเซิร์ฟเวอร์หลักสำหรับแอปพลิเคชันที่กำหนดเองได้

(หมายเหตุ: หากบริการต้องการพื้นที่จัดเก็บโปรดเลือกเซิร์ฟเวอร์หลักเดียวกันกับที่เลือกไว้ก่อนหน้านี้สำหรับทรัพยากรหน่วยเก็บข้อมูล)

ในกล่องโต้ตอบชื่อบริการค้นหาบริการสำหรับแอปพลิเคชันแบบกำหนดเองของคุณ

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

จากนั้นเลือกแท็กทรัพยากรแท็กทรัพยากรควรเป็นชื่อที่มีความหมายซึ่งจะช่วยให้ทีมไอทีของคุณระบุได้อย่างรวดเร็วว่าทรัพยากร SPS-L ใดที่ปกป้องแอปพลิเคชันหรือบริการของคุณ

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

หมายเหตุ:

1 การสร้างชุดการกู้คืนแอปพลิเคชันของลูกค้าสามารถทำได้โดยการมีส่วนร่วมกับทีมบริการระดับมืออาชีพของ SIOS Technology Corp.สำหรับข้อมูลเพิ่มเติมโปรดติดต่อ professional-services@us.sios.com

2 QuickCheck ของ QSP Recovery Kit สามารถดำเนินการด้านสุขภาพอย่างง่ายเท่านั้น (โดยใช้การดำเนินการ "สถานะ" ของคำสั่งบริการ) QSP ไม่รับประกันว่ามีการให้บริการหรือกระบวนการทำงาน หากจำเป็นต้องเริ่มต้นและ / หรือหยุดที่ซับซ้อนหรือจำเป็นต้องมีการตรวจสอบความสมบูรณ์ที่มีประสิทธิภาพมากขึ้นขอแนะนำให้ใช้ Generic Application หรือ Custom Application ARK

ผลิตซ้ำจาก SIOS