ข้ามไปยังเนื้อหา
กลับหน้ารายการบทความ

WorkSpaces Core Managed Instances เพิ่ม ModifyVolume ปรับขนาดและประสิทธิภาพดิสก์โดยไม่ต้อง Rebuild

AWS ประกาศ 26 ตุลาคมเพิ่ม API ปรับ volume แบบ in-place พร้อม idempotency token และติดตามสถานะได้ ตรวจผลที่ระบบไฟล์กับค่าใช้จ่ายก่อนใช้งาน

WorkSpaces Core Managed Instances เพิ่ม ModifyVolume ปรับขนาดและประสิทธิภาพดิสก์โดยไม่ต้อง Rebuild

AWS ประกาศเมื่อ 26 ตุลาคม 2026 ว่า Amazon WorkSpaces Core Managed Instances รองรับ ModifyVolume API สำหรับเปลี่ยนขนาด ชนิด IOPS และ throughput ของ volume แบบ in-place โดยไม่ต้องถอดดิสก์หรือรีสตาร์ต instance ก่อนหน้านี้การเปลี่ยนความจุหรือประสิทธิภาพของ managed instance ที่ใช้งานแล้วต้อง rebuild ข่าวนี้จึงช่วยลดขั้นตอนเปลี่ยน storage ของงานเดสก์ท็อปที่มีอยู่

สิ่งที่ API ปรับได้มีข้อแตกต่างตามชนิดดิสก์

ประกาศระบุการเพิ่มขนาดได้สูงสุด 16,384 GiB การสลับชนิด EBS ที่รองรับ การปรับ IOPS สำหรับ gp3, io1 และ io2 และการปรับ throughput สำหรับ gp3 พร้อม idempotency token และการติดตามผ่าน EC2 DescribeVolumesModifications ผู้ดูแลต้องตรวจข้อจำกัด EBS ที่เกี่ยวข้องกับชุดค่าจริงก่อนส่งคำขอ ไม่ควรตีความว่าเลือกทุกค่าได้อิสระโดยไม่มีเงื่อนไข

แก้ให้ตรงคอขวดก่อนเพิ่มทุกค่า

เดสก์ท็อปที่พื้นที่ใกล้เต็มกับเดสก์ท็อปที่รอ I/O เป็นปัญหาคนละแบบ ควรเก็บ free space, latency และลักษณะงานช่วงที่ผู้ใช้รู้สึกช้า แล้วเลือกการเปลี่ยนที่ตรงสาเหตุ หากปัญหาอยู่ที่ CPU หรือแอปติดต่อบริการเครือข่าย การเพิ่มความจุดิสก์อย่างเดียวอาจไม่ช่วย

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

Volume ใหญ่ขึ้นไม่ได้ยืนยันว่าระบบไฟล์พร้อมทันที

หลังส่งคำขอ ควรติดตามสถานะการปรับ volume และตรวจความจุที่ guest OS มองเห็นแยกกัน ขั้นตอนขยาย partition หรือ filesystem อาจขึ้นกับระบบปฏิบัติการและรูปแบบดิสก์ที่ใช้ จึงต้องตรวจคู่มือของสภาพแวดล้อมนั้น ไม่ควรสรุปจากผลตอบรับ API ว่าพื้นที่ในไดรฟ์ของผู้ใช้เพิ่มครบแล้ว

เลือกเครื่องทดลองที่สำรองข้อมูลแล้ว ตรวจว่าแอปยังเปิดไฟล์และบันทึกงานได้ตามปกติระหว่างและหลังการปรับ การไม่ต้อง restart ตามประกาศไม่ได้แทนการตรวจผลของ workload จริง โดยเฉพาะงานที่ไวต่อ latency หรือกำลังเขียนข้อมูลจำนวนมาก

Retry ต้องรู้ว่าคำขอเดิมสำเร็จหรือยัง

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

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

API พร้อมใน Region ที่มี WorkSpaces Core Managed Instances ตามประกาศ ส่วนการใช้งานผ่าน partner solution ต้องรอการรองรับของผู้ให้บริการนั้น ผู้ใช้ควรตรวจช่องทางที่ตนใช้จริงก่อนวางแผนเปลี่ยนงานผ่านหน้าจอของ partner

แหล่งต้นทาง: AWS WorkSpaces Core Managed Instances ModifyVolume ประกาศวันที่ 26 ตุลาคม 2026 เวลา 18:00 UTC