Cloud HM

MENU

Best Practice สำหรับ Veeam vSphere Proxy

Best Practice สำหรับ Veeam vSphere Proxy

Cloud HM - MKTTech News

Veeam Proxy ทำหน้าที่เป็นตัวกลางระหว่าง Veeam Backup Server และ Components อื่นๆ ใน Backup Infrastructure มีหน้าที่คอย Process และ Delivers backup traffic จึงสิ่งที่สำคัญมากสำหรับการทำ Backup & Replicate การเลือกใช้งาน Proxy ให้ถูกต้องเหมาะสมกับ Infrastructure ของคุณจะช่วยให้สามารถ Backup & Replicate ได้อย่างรวดเร็วและมีประสิทธิภาพ

ก่อนอื่นมารู้จักการทำงานของ Proxy ในแต่ละโหมดก่อนนะครับ โดยเราจะเรียกมันว่า Transport Modes ซึ่งจะมีอยู่ทั้งหมด 3 โหมดด้วยกัน

  • Direct storage access เป็นโหมดที่ Veeam สามารถอ่านเขียนข้อมูลบน Storage ที่เก็บข้อมูล VM และ Backup ได้โดยตรง ทำให้สามารถ Backup & Replicate ได้อย่างรวดเร็ว สามารถใช้ได้เฉพาะกับ Storage ประเภท Fiber Channel (FC) SAN, iSCSI SAN, NFS Storage และ Shared SAS เท่านั้น
  • Virtual Appliance (HotAdd) โหมดนี้ ตัว Proxy จะต้องเป็น VM เท่านั้นนะครับ โดยตัว Proxy จะทำการเอา vDisk ของ VM ที่ต้องการจะ Backup & Replicate มา Attached เข้ากับตัวมันเอง ทำให้สามารถอ่านเขียนข้อมูล VM ได้โดยตรงโดยไม่ต้องผ่าน Network ซึ่งก็ยังคงมีความเร็วมากกว่าโหมด Network แต่ไม่เท่า Direct storage access
  • Network โหมดนี้จะรองรับกับ Infrastructure ทุกรูปแบบ ข้อมูลทั้งหมดจะถูกส่งผ่าน LAN โดยใช้ Network Block Device protocol (NBD) จะเป็นโหมดที่ Transfer Data ได้ช้าที่สุด แต่ว่าถ้าหากคุณมี VM ขนาดเล็กจำนวนมาก, Network Throughput 10 GB และมี Data change ไม่เยอะนัก โหมดนี้จะเหมาะสมที่สุดกับการใช้งาน

ในการเลือกใช้งาน Transport Modes สามารถเลือกได้ทั้งแบบ Manual และแบบ Automatic หากเลือกใช้งานแบบ Automatic ตัว Veeam จะเลือกใช้งาน Mode ตามลำดับดังนี้ Direct storage access > Virtual appliance > Network

หลังจากรู้จักการทำงานของแต่ละโหมดไปแล้ว ทีนี้เรามาลองคำนวน Sizing ของ Proxy ที่เหมาะสมกับ Infrastructure ของเรากันบ้าง โดยเราสามารถคำนวนจำนวนความต้องการของ Proxy Tasks ได้ดังนี้

D = Data ต้นทาง หน่วยเป็น MB

W = ช่วงเวลาในการทำ Backup หน่วยเป็น วินาที

T = Throughput ที่ต้องการ หน่วยเป็น MB/s = D/W

CR = Data Change rate

CF = จำนวน Core CPU ที่ต้องใช้สำหรับ Full Backup = T/100

CI = จำนวน Core CPU ที่ต้องใช้สำหรับ Incremental Backup = (T * CR)/25

ตัวอย่างขนาดของ Infrastructure ที่เราใช้งาน เช่น

  • 1000 VMs
  • 100 TB ขนาดของ Storage ที่ใช้งานอยู่
  • ช่วงเวลาในการทำ Backup ภายใน 8 ชั่วโมง
  • มี Data change อยู่ที่ประมาณ 10%

ลองแปลงหน่วยให้เป็นตามสูตรก็จะได้ดังนี้

D = 100 TB * 1024 * 1024 = 104,857,600 MB

W = 8 hours * 3600 seconds = 28,800 seconds

T = 104857600/28800 = 3,641 MB/s

หากเราต้องการทำ Full Backup ให้ทันภายใน 8 ชั่วโมง ก็จะต้องใช้ CPU ทั้งหมด CF = T/100 ~ 36 cores

และใช้ CI = (T * CR)/25 ~ 14 cores สำหรับทำ Incremental

โดยการทำงานของ Proxy Task ต่อการ Process 1 VM disk จะใช้สเปค 1 vCPU และ Memory 2 GB ดังนั้น Resource ทั้งหมดที่เราต้องใช้สำหรับทำ Full Backups ก็คือ 36 cores and 72 GB RAM และ 14 cores and 28 GB RAM

สำหรับ Incremental Backups

ถ้าหาก Proxy เป็นเครื่อง Physical เราควรใช้ Server อย่างน้อย 2 เครื่อง และมี CPU อย่างน้อยเครื่องละ 18 core เพื่อป้องกัน Single point failure หาก Server มีปัญหาด้าน Hardware ด้วย แต่ถ้าตัว Proxy เป็น VM ทาง Veeam แนะนำให้ Proxy แต่ละตัวมี vCPU สูงสุด 8 core และเพื่อให้ตอบโจทย์กับตัวอย่างด้านบน เราจึงต้องสร้าง Proxy จำนวน 5 VMs

จากตัวอย่าง ถ้าเราต้องการจะ Improve ให้การ Backup ของเราเร็วขึ้นจาก Full Backups 8 ชั่วโมง เหลือ 4 ชั่วโมง เราสามารถใช้หลักการง่ายๆ โดยการ Double up(x2) จำนวน Proxy ได้เลย เช่นเดียวกันกับขนาดของ Data change หาก Data change มีขนาดเพิ่มขึ้นจาก 10% เป็น 20% ก็สามารถใช้หลักการเดียวกันได้

ในกรณีที่เรามี Proxy Resource ไม่พอกับความต้องการ เราสามารถคำนวนเวลาที่ใช้ในการทำ Backup ได้เช่นเดียวกัน จากสูตร

WS = D/(CI*100)

W = WS/3600

ตัวอย่างเช่น เราต้องการคำนวนเวลาที่ใช้ในการทำ Full Backups โดยใช้ Proxy Resource ที่เพียงพอแค่สำหรับทำ Incremental ซึ่งก็จะคำนวนได้เท่ากับ

WS = 104857600/(14 * 100)

W = WS/3600 ~ 21 hours

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

ข้อมูลอ้างอิง

— Cloud HM