News:

Brought to you NINE-T Co.,ltd.

Main Menu

Recent posts

#1
สำหรับผู้ที่ดาวน์โหลด ESXi 8.0U3e ก็เพราะว่า ตัวฟรีนั้นมีข้อจำกัดจำนวนมาก แต่ที่สำคัญคือ ท่านจะไม่สามารถใช้ vStorage Engine API ได้ผลเสียก็คือท่านจะไม่สามารถใช้ 3rd Party backup เช่น Veeam, Nakivo หรือตัวอื่นๆ ได้เลย เพราะฉะนั้น สำหรับผู้ที่มองหาไปใช้กับ Production ต้องบอกว่าลืมได้เลย

ข้อความที่ท่านอาจจะได้รับเมื่อ ทำการ backup ผ่าน Veeam

7/6/2025 9:17:38 AM :: Processing WinServer2022 Error: Current vSphere license or ESXi version prohibits execution of the requested operation. 
7/6/2025 9:18:32 AM :: Failed to create VM snapshot. Error: CreateSnapshot failed, vmRef 1, timeout 1800000, snName VEEAM BACKUP TEMPORARY SNAPSHOT, snDescription Please do not delete this snapshot. It is being used by Veeam Backup., memory False, quiesce False 
7/6/2025 9:18:40 AM :: Error: Current vSphere license or ESXi version prohibits execution of the requested operation. 
#2
Proxmox VE / Volume Shadow Copy Failed afte...
Last post by jimmy - June 08, 2025, 09:36:03 AM
สำหรับท่านที่ใช้ Volume Shadow Copy ใน File Server อยู่ อาจจะทำให้ มันทำงานไม่ได้หลังจากการย้าย
ให้ท่านเข้าไปที่นี่ และ เช็คว่ามี UpperFilters หรือปล่าว ถ้าไม่มีก็เพิ่มไป

ไปที่ key id ดังกล่าว → New → Multi-String Value.

ตั้งชื่อ UpperFilters

ตั้งค่าเป็น volsnap

Shadow Copy ก็จะกลับมาทำงานตามปกติ
#3
Proxmox VE / การ remove vmware tools หลังกา...
Last post by jimmy - June 08, 2025, 09:32:30 AM
ต้องบอกว่า จริงๆ แล้วก่อนการ migrate มายัง Proxmox VE นั้นท่านจะต้องทำการ uninstall VMware Tools ก่อน แต่ถ้าท่านลืมจะทำอย่างไร มีคนสร้าง Powershell Script ทำสำหรับการดำเนินการดังกล่าวด้วยนะ
ไปดาวน์โหลดมาเลย

https://gist.github.com/broestls/f872872a00acee2fca02017160840624

ท่านนำมาแล้ว ก็เอามา save เป็น file อาจจะชื่อ remove-vmware-tools.ps1 ก็ได้และรัน Powershell ในระดับ admin
#4
สำหรับบางท่านที่ทำการ add VeeamPVEworker และกด test แล้วปรากฏว่า จะขึ้นว่า Failed to connect to the worker core service ให้ท่านเช็คว่ามี NIC กี่ตัวในระบบ เนื่องจาก Veeam จะเชื่อมต่อตามลำดับโดยไม่สนใจว่า NIC นั้นจะ unplugged อยู่หรือไม่ เพราะฉะนั้น ถ้ามี NIC ตัวไหนที่ไม่ได้ใช้ต้อง disabled
#5
กระบวนการ Failover to Replica บน Veeam Backup and Replication เป็นกระบวนการที่ใช้เมื่อจำเป็นต้องสลับการทำงานของระบบไปยังเครื่องจำลอง (Replica) ในกรณีที่ระบบหลักเกิดปัญหา หรือไม่สามารถใช้งานได้ กระบวนการนี้มีขั้นตอนหลัก ๆ ดังนี้:

1. Initiate Failover
รายละเอียด: ผู้ดูแลระบบจะต้องเปิดใช้งานกระบวนการ Failover ผ่านทาง Veeam Backup & Replication console โดยการเลือกเครื่องจำลองที่ต้องการสลับการทำงานไปใช้
สิ้นสุดกระบวนการ: เมื่อเลือกเครื่องจำลองแล้ว กระบวนการจะเริ่มต้นการ Failover
2. Switching to Replica
รายละเอียด: ระบบจะทำการสลับการทำงานไปยังเครื่องจำลอง โดยการตั้งค่าเครื่องจำลองให้เป็นเครื่องที่ใช้งานอยู่แทนเครื่องหลัก ซึ่งระบบจะตรวจสอบและทำการกำหนด IP address รวมถึงการเชื่อมต่อเครือข่ายอื่น ๆ ให้กับเครื่องจำลอง
สิ้นสุดกระบวนการ: เมื่อเครื่องจำลองสามารถทำงานได้เต็มรูปแบบ และผู้ใช้สามารถเข้าถึงทรัพยากรบนเครื่องจำลองได้ กระบวนการนี้ก็จะสิ้นสุดลง
3. Monitoring and Verifying
รายละเอียด: ระบบจะตรวจสอบการทำงานของเครื่องจำลองหลังจากที่มีการสลับการทำงาน และทำการตรวจสอบว่าการทำงานเป็นไปตามที่คาดหวัง ทั้งในด้านประสิทธิภาพและความเสถียร
สิ้นสุดกระบวนการ: เมื่อการตรวจสอบเสร็จสิ้นและระบบยืนยันว่าเครื่องจำลองทำงานได้อย่างถูกต้อง กระบวนการนี้จะสิ้นสุดลง

อย่าลืมว่า กระบวนการ failover นั้นเป็นกระบวนการที่ไม่สิ้นสุด หมายถึง ท่านจะต้องทำสิ่งต่างๆ เหล่านี้เพื่อให้กระบวนการ failover นั้นจบลงด้วยทางเลือกใดๆ ดังต่อไปนี้

1. Permanent Failover
รายละเอียด: ในกรณีที่ต้องการให้เครื่องจำลองกลายเป็นเครื่องหลักใหม่อย่างถาวร ผู้ดูแลระบบจะต้องทำการ Permanent Failover ซึ่งเป็นการยืนยันการเปลี่ยนแปลงนี้
สิ้นสุดกระบวนการ: เมื่อทำการ Commit เรียบร้อยแล้ว ระบบจะทำการลบสถานะของเครื่องจำลองและกำหนดให้เครื่องนั้นเป็นเครื่องหลักใหม่อย่างถาวร
2. Failback
รายละเอียด: เมื่อระบบหลักสามารถกลับมาทำงานได้แล้ว ผู้ดูแลระบบสามารถทำการ Failback กลับไปยังเครื่องหลักเดิม โดยระบบจะทำการซิงค์ข้อมูลจากเครื่องจำลองไปยังเครื่องหลักและทำการสลับการทำงานกลับไปยังเครื่องหลัก
เมื่อระบบทำการย้ายการเปลี่ยนแปลงที่เกิดขึ้นในระหว่างที่ท่าน failover ไปยัง replica นั้น จะต้องเลือกที่จะทำการ บันทึกการเปลี่ยนแปลงนั้นด้วย การทำ Commit failback และ สถานะของ replica ก็จะกลับไปเป็นปกติ

ในขณะที่ ถ้า VM ต้นทางมีปัญหา ไม่สามารถทำงานได้ ทำให้ท่านจะต้องใช้ replica ในการทำงานต่อไป สถานะของ replica จะอยู่ในสถานะ failover ต่อไป

3. Undo Failover: เมื่อการสลับกลับมาที่เครื่องหลักเสร็จสิ้น และเครื่องหลักสามารถทำงานได้ตามปกติ กระบวนการนี้ก็จะสิ้นสุดลง
กระบวนการทั้งหมดนี้เป็นการทำงานที่สำคัญเพื่อให้ระบบสามารถดำเนินการได้อย่างต่อเนื่องแม้ในกรณีที่เกิดปัญหากับเครื่องหลัก และการสิ้นสุดกระบวนการจะเกิดขึ้นเมื่อระบบสามารถทำงานได้ตามที่ตั้งใจ ไม่ว่าจะเป็นเครื่องจำลองหรือเครื่องหลัก
#6
สำหรับลูกค้าที่้ต้องการใช้งาน RPO ให้ได้ต่ำที่สุดนั้น เช่นในระดับนาที หรือ ไม่ถึง 1 นาที ท่านสามารถทำได้ โดยการใช้คุณสมบัติที่เรียกว่า CDP ใน Veeam และบวกกับ องค์ประกอบและสภาพแวดล้อมเหล่านี้
1. vCenter
2. Veeam CDP I/O Filter

โดยที่ท่านจะต้องทำการติดตั้ง Veeam CDP I/O Filter นั้นใน vCenter หลังจากนั้น vCenter ก็จะเข้าไปทำการติตตั้ง I/O Filter ในแต่ละ ESXi Host ซึ่ง คุณสมบัติ I/O Filter นี้จะทำงานโดยใช้ VAIO มีหน้าที่คอยจับการเปลี่ยนแปลงบน disk และ นำไปเขียนเป็น backup ไว้ เพื่อให้ท่านได้ RPO ที่น้อยที่สุด

แต่ถามว่า หากท่านไม่ได้ใช้ vCenter และ ทำ Cluster ไว้ แต่ต้องการติดตั้ง ใน ESXi host โดยตรงได้หรือไม่ คำตอบคือ : ไม่ได้ ท่านต้องทำผ่าน vCenter เท่านั้น

และ หากท่านต้องการ RPO ที่ต่ำที่สุดเท่าที่จะเป็นไปได้โดยไม่สามารถใช้ I/O Filter ได้ ด้วยเหตุผลบางอย่างที่ไม่เอื้ออำนวย จะต้องทำอย่างไร ท่านสามารถใช้ การตั้ง Schedule -> Periodically Every -> Continuous ซึ่งการทำงานของมันก็คือ
1. ระบบจะทำ snapshot
2. โกย snapshot ไปเป็น backup file
3. ลบ snapshot
4. snapshot ใหม่ และ เริ่มกระบวนการเดิมอีกครั้ง

ทั้งนี้ท่านจะเห็นว่า ความเร็วและ RPO ที่ได้นั้น จะขึ้นอยู่กับหลายอย่าง เช่นเวลาที่ใช้ในการ snapshot และ เวลาที่ไปเขียน backup ถ้าท่านมีระบบ disk ที่เร็วเช่น NVME และมี network ความเร็วสูง ท่านก็จะได้ RPO ที่ต่ำ แต่อย่างลืมว่า การทำแบบนี้ในเครื่องที่มีประสิทธิภาพต่ำเช่น SATA Disk จะมีความเสี่ยงในการที่จะทำให้ VM นั้นทำงานช้าลง
#7
เรียกว่าเป็น Option สำคัญที่พลาดไม่ได้เลยสำหรับการ สำรองข้อมูลขึ้น Object Storage ไม่ว่าจะเป็น S3-Compatible Storage เช่น Wasabi หรือเจ้าอื่นๆ เพื่อให้ Veeam นั้นทำการเช็คความผิดพลาดของการสำรองข้อมูลอย่างสม่ำเสมอ เพื่อให้แน่ใจว่า เวลากู้ข้อมูลคืนจะได้ไม่มีปัญหา
#8
สำหรับการทำ synthetic full นั้นเป็นการผนวก incremental files ที่เกิดขึ้นในอาทิตย์ที่ผ่านมามาสร้างเป็นไฟล์ใหม่ แต่การทำเช่นนั้นบน NTFS File System นั้นจะค่อนข้างช้ามาก เพราะเหมือนเขียนไฟล์ใหม่ ข้อแนะนำอย่างมากคือ ให้เปลี่ยนไปใช้ ReFS ใน folder ที่เก็บ backup files ซึ่งก็คือใน repository นั่นเอง แต่อย่าลืมนะครับว่า ReFS นั้นมีให้ใช้ใน Windows Server เท่านั้น Windows 10/11 ไม่มีนะ เพราะฉะนั้น ท่านควรจะลง Veeam backup ใน Windows Server หรือว่าใช้ Remote Repo ที่เป็น Windows Server

จากตัวอย่างในรูป เป็นการทำ synthetic full บน NTFS พบว่า ใช้เวลาไปแล้ว เกือบ 5 ชม. เพิ่งจะได้แค่ 62% โดยไฟล์มีขนาดเพียง 1.6T เท่านั้น บน HDD แต่ถ้าท่านเปลี่ยนไปเป้น ReFS ก็จะเหลือ 1-2 ชม.เท่านั้น

#9
หลายคนทำ เราก็เลย จัดไป ว่าค่าแต่ละตัวหมายถึงอะไร

Total size = เนื้อที่ที่เราสั่ง Backup ทั้งหมดของ VM ตามตัวอย่างคือ 1.5TB
Data Read = เนื้อที่ที่เกิดจากการเปลี่ยนแปลงจากการสำรองครั้งนี้แล้ว เช่นในกรณีนี้คือ เฉพาะค่าความเเปลี่ยนแปลงจาก CBT ตัวอย่างคือ 13.9GB
Transferred = ขนาดของข้อมูลที่ถูกส่งผ่านไปยังปลายทาง ซึ่งก็คือ repository แน่นอนว่า ในกรณีนี้คือ 4.6GB ทั้งนี้เพราะว่า
มันคือส่วนที่เปลี่ยนแปลงเท่านั้น ไม่ใช่ข้อมูลทั้งหมด
Backup Size = ค่าตรงนี้จะเห็นว่า ก็จะน้อยลงกว่าค่า Transfer เพราะมันถูกบีบอัดลงอีก
Dedupe = มีค่า 1.0x ก็คือเท่าเดิม ซึ่งปกติ ค่านี้จะเปลี่ยนแปลงในการทำ full backup เท่านั้น
Compresssion = มีการใช้การบีบอัด ซึ่งก็คือค่า data read / transferred หรือ เนื้อที่จริงและเนื้อที่ที่ ถูกขนถ่ายไปยังปลายทาง
#10
วันนี้เราก็ได้มี case ของลูกค้าที่เมื่อทำการ migrate vm ข้าม storage แล้ว หลุดดื้อๆ เลย เรียกว่า ไม่แค่นั้น แต่ยังทำให้ datastore นั้นขึ้นว่า inaccessible รั่วคราว เลย ใน case นี้เราทำการทดสอบแล้วพบว่า มีการใช้ storage รุ่นที่เป็น home-use เราไม่สามารถบอกยี่ห้อได้ เพราะ เราพบ 2-3 ยี่ห้อเลยทีเดียว แต่ก็นั่นล่ะครับ เพราะเอา storage ที่คุณภาพเหมาะกับงานใช้ส่วนตัวมากกว่าที่จะเอามาทำ production

อย่างในตัวอย่าง ก็เป็นการ transfer 3 vms สบายๆ เลย ในสภาวะปกติ