Hystax Cloud Migration: ขี่เมฆ

หนึ่งในผู้เล่นอายุน้อยในตลาดโซลูชั่นการกู้คืนความเสียหายคือ Hystax ซึ่งเป็นสตาร์ทอัพชาวรัสเซียในปี 2016 เนื่องจากหัวข้อการกู้คืนความเสียหายเป็นที่นิยมอย่างมากและตลาดมีการแข่งขันสูง สตาร์ทอัพจึงตัดสินใจมุ่งเน้นไปที่การโยกย้ายระหว่างโครงสร้างพื้นฐานคลาวด์ที่แตกต่างกัน ผลิตภัณฑ์ที่ช่วยให้คุณจัดการการโยกย้ายไปยังคลาวด์ที่ง่ายและรวดเร็วจะมีประโยชน์มากสำหรับลูกค้าของ Onlanta - ผู้ใช้ oncloud.ru. นั่นทำให้ฉันได้รู้จัก Hystax และเริ่มทดสอบฟีเจอร์ต่างๆ ของมัน และสิ่งที่เกิดขึ้นฉันจะบอกในบทความนี้

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

สิ่งนี้ช่วยให้คุณสร้างไม่เพียงแต่โซลูชัน DR เพื่อปรับปรุงความทนทานต่อข้อผิดพลาดของบริการ แต่ยังย้ายทรัพยากรระหว่างไซต์ต่างๆ และไฮเปอร์สเกลเลอร์ได้อย่างรวดเร็วและยืดหยุ่น เพื่อเพิ่มการประหยัดต้นทุน และเลือกโซลูชันที่ดีที่สุดสำหรับบริการเฉพาะในขณะนี้ นอกเหนือจากแพลตฟอร์มที่ระบุไว้ในชื่อภาพแล้ว บริษัทยังร่วมมืออย่างจริงจังกับผู้ให้บริการคลาวด์ของรัสเซีย เช่น Yandex.Cloud, CROC Cloud Services, Mail.ru และอื่นๆ อีกมากมาย เป็นที่น่าสังเกตว่าในปี 2020 บริษัทได้เปิดศูนย์ R&D ที่เมือง Skolkovo 

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

ดังนั้นงานทดสอบของเราจะประกอบด้วยการย้ายจากไซต์ทดสอบ VMware ของฉันและเครื่องทางกายภาพไปยังไซต์ของผู้ให้บริการที่ใช้ VMware ด้วย ใช่ มีวิธีแก้ไขปัญหามากมายที่สามารถนำการย้ายข้อมูลไปใช้ แต่เราถือว่า Hystax เป็นเครื่องมือสากล และการทดสอบการย้ายข้อมูลในการผสมผสานที่เป็นไปได้ทั้งหมดนั้นเป็นเพียงงานที่ไม่สมจริง ใช่แล้ว และคลาวด์ Oncloud.ru นั้นถูกสร้างขึ้นบน VMware โดยเฉพาะ ดังนั้นแพลตฟอร์มนี้ในฐานะเป้าหมายจึงทำให้เราสนใจในระดับที่มากขึ้น ต่อไปฉันจะอธิบายหลักการทำงานขั้นพื้นฐานซึ่งโดยรวมไม่ได้ขึ้นอยู่กับแพลตฟอร์มและสามารถเปลี่ยน VMware จากด้านใดก็ได้ด้วยแพลตฟอร์มจากผู้ขายรายอื่น 

ขั้นตอนแรกคือการปรับใช้ Hystax Acura ซึ่งเป็นแผงควบคุมของระบบ

Hystax Cloud Migration: ขี่เมฆ
มันขยายจากเทมเพลต ด้วยเหตุผลบางประการ ในกรณีของเรา มันไม่ถูกต้องทั้งหมด และแทนที่จะใช้ 8CPU ที่แนะนำ กลับใช้ 16Gb โดยใช้ทรัพยากรเพียงครึ่งหนึ่ง ดังนั้น คุณต้องจำไว้ว่าต้องเปลี่ยนแปลง มิฉะนั้นโครงสร้างพื้นฐานภายใน VM ซึ่งทุกอย่างถูกสร้างขึ้นจะไม่เริ่มต้นด้วยคอนเทนเนอร์และพอร์ทัลจะไม่พร้อมใช้งาน ใน ข้อกำหนดในการปรับใช้ มีการอธิบายทรัพยากรที่จำเป็นโดยละเอียด รวมถึงพอร์ตสำหรับส่วนประกอบของระบบทั้งหมด 

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

Hystax Cloud Migration: ขี่เมฆ
Hystax Cloud Migration: ขี่เมฆ
ตำแหน่งข้อมูล – IP หรือ FQDN ของ vCenter ของเรา 
เข้าสู่ระบบและรหัสผ่าน - มีความชัดเจนที่นี่ 
ชื่อโฮสต์ ESXi เป้าหมายเป็นหนึ่งในโฮสต์ในคลัสเตอร์ของเราที่จะถูกจำลองแบบไป 
พื้นที่เก็บข้อมูลเป้าหมายเป็นหนึ่งในพื้นที่เก็บข้อมูลในคลัสเตอร์ของเราที่จะถูกจำลองแบบไป
IP สาธารณะของแผงควบคุม Hystax Acura - ที่อยู่ที่จะใช้แผงควบคุมได้

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

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

แต่กลับไปสู่การใช้งาน ก่อนอื่น หลังจากการตั้งค่าแผงควบคุมครั้งแรก เราจำเป็นต้องสร้างผู้เช่ารายแรกในระบบของเรา

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

Hystax Cloud Migration: ขี่เมฆ
ในรูปแบบของการเพิ่มคลาวด์ใหม่ เราระบุพารามิเตอร์เดียวกันกับในระหว่างการกำหนดค่าเริ่มต้น (เราสามารถใช้โฮสต์เดียวกันได้) ระบุพื้นที่เก็บข้อมูลที่จำเป็นสำหรับลูกค้ารายใดรายหนึ่ง และตอนนี้ในพารามิเตอร์เพิ่มเติมที่เราสามารถระบุแยกกันได้แล้ว ทรัพยากรพูลที่ต้องการ {"resource_pool" :"YOUR_POOL_NAME"} 

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

Hystax Cloud Migration: ขี่เมฆ
ในขณะเดียวกัน ก็ไม่เชื่อมโยงกับผู้เช่าที่สร้างขึ้น และลูกค้าของเราทุกคนจะดำเนินการผ่านมันไป (หรือหลังจากนั้นหลายรายการ หากเราปรับใช้) เอเจนต์หนึ่งรายรองรับ 10 เซสชันพร้อมกัน หนึ่งเซสชันนับเป็นรถยนต์หนึ่งคัน มันไม่สำคัญว่าจะมีดิสก์จำนวนเท่าใด ในปัจจุบัน ยังไม่มีกลไกในการปรับขนาดเอเจนต์ใน Acura สำหรับ VMware มีช่วงเวลาที่ไม่พึงประสงค์อีกประการหนึ่ง - เราไม่สามารถดู "การใช้งาน" ของตัวแทนนี้จากแผง Acura เพื่อสรุปว่าเราจำเป็นต้องปรับใช้เพิ่มเติมหรือการติดตั้งปัจจุบันก็เพียงพอแล้ว เป็นผลให้ขาตั้งมีลักษณะดังนี้:

Hystax Cloud Migration: ขี่เมฆ
ขั้นตอนต่อไปในการเข้าถึงพอร์ทัลลูกค้าของเราคือการสร้างบัญชี (และประการแรก บทบาทที่จะใช้กับผู้ใช้รายนี้)

Hystax Cloud Migration: ขี่เมฆ
Hystax Cloud Migration: ขี่เมฆ
ขณะนี้ลูกค้าของเราสามารถใช้พอร์ทัลได้อย่างอิสระ สิ่งที่เขาต้องทำคือดาวน์โหลดตัวแทนจากพอร์ทัลและติดตั้งไว้ที่ฝั่งของเขา เอเจนต์มีสามประเภท: Linux, Windows และ VMware

Hystax Cloud Migration: ขี่เมฆ
สองรายการแรกนั้นวางบนฟิสิกส์หรือบนเครื่องเสมือนบนไฮเปอร์ไวเซอร์ที่ไม่ใช่ VMware ไม่จำเป็นต้องกำหนดค่าเพิ่มเติมที่นี่ เจ้าหน้าที่จะดาวน์โหลดและรู้แล้วว่าจะต้องเคาะที่ใด และภายในไม่กี่นาที รถก็จะมองเห็นได้ในแผงควบคุมของ Acura ด้วยเอเจนต์ VMware สถานการณ์จะซับซ้อนขึ้นเล็กน้อย ปัญหาคือมีการดาวน์โหลด Agent สำหรับ VMware จากพอร์ทัลที่เตรียมไว้แล้วและมีการกำหนดค่าที่จำเป็น แต่ตัวแทน VMware นอกเหนือจากการทราบเกี่ยวกับพอร์ทัล Acura ของเราแล้ว ยังจำเป็นต้องรู้เกี่ยวกับระบบเสมือนจริงที่จะนำไปใช้อีกด้วย

Hystax Cloud Migration: ขี่เมฆ
จริงๆ แล้วระบบจะขอให้เราระบุข้อมูลนี้เมื่อทำการดาวน์โหลด VMware agent เป็นครั้งแรก ปัญหาคือในยุคแห่งความรักสากลต่อความปลอดภัย ไม่ใช่ทุกคนที่ต้องการระบุรหัสผ่านผู้ดูแลระบบบนพอร์ทัลของผู้อื่น ซึ่งค่อนข้างเข้าใจได้ จากภายใน หลังจากปรับใช้แล้ว ไม่สามารถกำหนดค่าเอเจนต์ได้ไม่ว่าด้วยวิธีใดก็ตาม (คุณสามารถเปลี่ยนได้เฉพาะการตั้งค่าเครือข่ายเท่านั้น) ที่นี่ฉันมองเห็นปัญหากับลูกค้าที่ระมัดระวังเป็นพิเศษ 

ดังนั้นหลังจากติดตั้งตัวแทนแล้วเราก็สามารถกลับไปที่แผง Acura และดูรถของเราทั้งหมดได้

Hystax Cloud Migration: ขี่เมฆ
เนื่องจากฉันทำงานกับระบบมาหลายวันแล้ว ฉันจึงมีรถยนต์ในรัฐต่างๆ ฉันมีทั้งหมดอยู่ในกลุ่มเริ่มต้น แต่คุณสามารถสร้างกลุ่มแยกกันและโอนรถไปให้ได้ตามต้องการ สิ่งนี้จะไม่ส่งผลกระทบใด ๆ - เฉพาะการนำเสนอข้อมูลเชิงตรรกะและการจัดกลุ่มเพื่อการทำงานที่สะดวกยิ่งขึ้น สิ่งแรกและสำคัญที่สุดที่เราต้องทำหลังจากนี้คือการเริ่มกระบวนการย้ายข้อมูล เราสามารถทำได้ด้วยตนเองหรือโดยการตั้งค่ากำหนดการ รวมถึงในจำนวนมากสำหรับเครื่องจักรทั้งหมดในคราวเดียว

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

Hystax Cloud Migration: ขี่เมฆ
ชุดพารามิเตอร์เมื่อสร้างแผน DR จะแตกต่างกันไปขึ้นอยู่กับโครงสร้างพื้นฐานที่คุณจะย้าย มีชุดพารามิเตอร์ขั้นต่ำสำหรับสภาพแวดล้อม VMware ไม่รองรับ Re-IP สำหรับเครื่องเช่นกัน ในเรื่องนี้เราสนใจประเด็นต่อไปนี้: ในคำอธิบาย VM พารามิเตอร์ "subnet": "VMNetwork" ซึ่งเราผูก VM กับเครือข่ายเฉพาะในคลัสเตอร์ อันดับ – เกี่ยวข้องเมื่อย้าย VM หลายเครื่อง โดยจะกำหนดลำดับที่จะเปิดตัว รส – อธิบายการกำหนดค่า VM ในกรณีนี้ – 1CPU, RAM 2GB ในส่วนเครือข่ายย่อย เรากำหนดว่า "subnet": "VMNetwork" เชื่อมโยงกับ VMware "VM Network" 

เมื่อสร้างแผน DR ไม่มีทางที่จะ “แยก” ดิสก์ระหว่างพื้นที่เก็บข้อมูลต่างๆ ได้ พวกเขาจะอยู่ในพื้นที่เก็บข้อมูลเดียวกันกับที่กำหนดไว้สำหรับคลาวด์ไคลเอนต์นี้ และหากคุณมีดิสก์ที่มีคลาสต่างกัน สิ่งนี้อาจทำให้เกิดปัญหาเมื่อสตาร์ทเครื่อง และหลังจากสตาร์ทและ "แยก" VM ออกจาก Hystax ก็จะยัง ต้องการดิสก์การโยกย้ายแยกต่างหากไปยังที่เก็บข้อมูลที่จำเป็น จากนั้นเราก็ต้องดำเนินการตามแผน DR และรอให้รถของเราขึ้น กระบวนการแปลง P2V/V2V ก็ต้องใช้เวลาเช่นกัน สำหรับเครื่องทดสอบขนาด 100GB ที่ใหญ่ที่สุดของฉันซึ่งมีดิสก์สามตัว การดำเนินการนี้ใช้เวลาสูงสุด 10 นาที

Hystax Cloud Migration: ขี่เมฆ
หลังจากนั้น คุณควรตรวจสอบ VM ที่ทำงานอยู่ บริการบนนั้น ความสอดคล้องของข้อมูล และการตรวจสอบอื่นๆ 

จากนั้นเรามีสองทางเลือก: 

  1. ลบ - ลบแผน DR ที่กำลังทำงานอยู่ การดำเนินการนี้จะปิดการทำงานของ VM ที่ทำงานอยู่ แบบจำลองเหล่านี้จะไม่ไปไหนทั้งนั้น 
  2. ถอด - ฉีกรถจำลองออกจาก Acura เช่น เสร็จสิ้นกระบวนการย้ายข้อมูลจริงๆ 

ข้อดีของการแก้ปัญหา: 

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

cons 

  • รองรับ Vmware ไม่เพียงพอ
  • ไม่มีโควต้าสำหรับผู้เช่าจากแพลตฟอร์ม 

ฉันยังได้ส่งคำขอคุณลักษณะ ซึ่งเราได้ส่งมอบให้กับผู้ขายแล้ว:

  1. การตรวจสอบการใช้งานและการปรับใช้จาก Acura Management Console สำหรับ Cloud Agents
  2. ความพร้อมของโควต้าสำหรับผู้เช่า 
  3. ความสามารถในการจำกัดจำนวนการจำลองและความเร็วพร้อมกันสำหรับผู้เช่าแต่ละราย 
  4. รองรับ VMware vCloud Director; 
  5. การสนับสนุนกลุ่มทรัพยากร (ใช้งานระหว่างการทดสอบ)
  6. ความสามารถในการกำหนดค่าเอเจนต์ VMware จากด้านข้างของเอเจนต์เอง โดยไม่ต้องป้อนข้อมูลรับรองจากโครงสร้างพื้นฐานไคลเอนต์ในแผง Acura
  7.  "การแสดงภาพ" ของกระบวนการเริ่มต้น VM เมื่อเริ่มต้นแผน DR 

สิ่งเดียวที่ทำให้ฉันวิพากษ์วิจารณ์ครั้งใหญ่คือเอกสารประกอบ ฉันไม่ชอบ "กล่องดำ" มากนัก และชอบเมื่อมีเอกสารโดยละเอียดเกี่ยวกับวิธีการทำงานของผลิตภัณฑ์ภายใน และหากสำหรับ AWS และ OpenStack มีการอธิบายผลิตภัณฑ์ไม่มากก็น้อย แสดงว่าสำหรับ VMware ก็จะมีเอกสารประกอบเพียงเล็กน้อย 

มีคู่มือการติดตั้งที่อธิบายเฉพาะการใช้งานแผงควบคุม Acura และไม่มีคำอธิบายเกี่ยวกับความจำเป็นในการใช้ Cloud Agent มีสเปกสินค้าครบชุดถือว่าดี มีเอกสารประกอบที่อธิบายการตั้งค่า "จากและถึง" โดยใช้ AWS และ OpenStack เป็นตัวอย่าง (แม้ว่าจะทำให้ฉันนึกถึงโพสต์ในบล็อกมากกว่า) และมีฐานความรู้ที่เล็กมาก 

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

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

เรากำลังมองหาทีม หัวหน้าวิศวกรระบบตรวจสอบ. อาจจะเป็นคุณเหรอ?

ที่มา: will.com

เพิ่มความคิดเห็น