Guest Memory VS Host Memory

อ้างอิงจาก โพสก่อนหน้านี้ นะครับ vSphere 5 Memory Management Fundamental
 หวังว่ายังคงจำ  Physical memory กับ Machine Memory กันได้นะครับ

คราวนี้เราจะนำความรู้จากโพสที่แล้วนั้น มาทำความเข้าใจกับ parameter ต่างๆบนหน้าต่างของ vSphere Client








       จากรูปทางฝั่งซ้ายจะเห็นได้เลยนะครับว่า เครื่อง VM นี้ เซ็ต memory ไว้ที่ประมาณ  7 GB (7168 MB) 

เริ่มจาก
       Memory Overhead = 87.68 MB    Memory Overhead  นั้นเป็นmemory ที่  ESXi ใช้ไปในการ virtualize VM เครื่องนี้  เนื่องจาก  kernel นั้นจำเป็นต้องสำรอง memory ส่วนหนึ่งไว้เพื่อใช้ในการจัดการ  memory ของ Guest นั้นๆ   (Machine memory )
      Consumed Host Memory = 1813 MB  เป็น memory จริง (Machine memory) ที่ Guest ใช้ไปในขณะนั้น
      Active Guest Memory     =  150 MB    เป็น memory จริง (Machine memory) ที่ ของ Guest นั้น ESXi เห็นว่า Active อยู่
   
     ดังนั้น สำหรับเครื่อง Windows  เครื่องนี้นั้น  configure  memory ไว้ที่  7GB (Maximum)  แต่ใช้ machine memory จริงๆ แค่ 1813 MB  โดย  machine memory ที่ active จริงๆนั้นมีแค่ 150 MB  
 
 Note: 1.ค่าเหล่านี้ เป็นค่าของ machine memory ทั้งสิ้น แต่ค่าที่เราเห็นจาก Task manager บน VM นั้นๆ เป็นค่าที่ Guest OS (Windows)  นั้นเห็น (Physical memory)    ดังนั้นทั้งสองค่าจะไม่เท่ากันนะครับ เนื่องจากเป็นค่าของ  memory ที่มาจากคนละ layer กัน
               2. ใน vSphere client นั้น จะใช้ host memory แทนคำว่า  machine memory นะครับ
มาดูรูปถัดไปกันนะครับ (คนละ  VM กับรูปแรกนะครับ )

       
         เครื่อง VM นี้เซ็ต memory ไว้  4 GB   โดยกิน host memory ไปแล้ว 1.83 GB และเสียค่า overhead ไป  59 MB  โดย  59 MB นี้จะรวมอยู่ใน  1.83 GB
         ต่อมา เราจะเห็นได้ว่า  Private Memory (Host Memoryของ Guest ที่ไม่ได้ถูก Shared )  คือ 1.77 GB  โดย  VM เครื่องนี้  share memory กับ VM เครื่องอื่นๆประมาณ 2.15 GB โดยยังไม่ได้ใช้ memory (เหลือ)อยู่ 84 MB (1.77 GB + 2.15 GB + 84MB = 4 GB)
Balloon , swap และ  compressed  มีค่าเป็นศูนย์สื่อว่า ระบบนั้นยังมี memory เพียงพอ  จึงไม่ต้องไปใช้  swap  ,ไม่ต้องใช้  balloon  และไม่ต้อง  compress memory  ดังนั้นจะเห็นได้ว่าที่กินไปทั้งหมด 1.83GB นั้น เป็นของตัวเอง 1.77GB + 59 MB ทีมาจาก overhead  นั่นเอง

 ผมหวังว่าคงจะเข้าใจ parameter  ต่างๆของ memory มากขึ้นแล้วนะครับ   ซึ่งจะช่วยในการแก้ปัญหาที่เกี่ยวกับ memory เป็นอย่างมากครับ
       
 
     

vSphere 5 Memory Management Fundamental

สวัสดีครับ

       ห่างหายกันไปนานมากกนะคับ  พอดีผมติดธุระโน่นนี่  จนลืมกลับมาเขียน  blog

      วันนี้ผมอยากจะมาพูดเกี่ยวกับ การบริหารจัดการ memory ของvSphere 5  เนื่องจากยังมีหลายคนที่เข้าใจผิด และสับสนอยู่ 

       ในเวอชั่น 5 นั้น   ESXi จะใช้ทั้งหมด 5 วิธีด้วยกันในการจัดการและบริหาร Memory

        1. TPS (Transparent Page Sharing)

        2.Ballooning

        3.Memory Compression

        4.Hyperisor Swapping

        5.Swap to SSD  ( New in vSphere 5)

       แต่ก่อนที่ผมจะเริ่มอธิบายแต่ละอันนั้น  ผมขอปูพื้นนิดนึงเกี่ยวกับ Layer ของ memory ในโลก virtualize  นิดนึงครับ

       Virtualization นั้นจะแบ่ง memory เป็น 3 Layer ด้วยกันคือ

       Virtual memory     ,Physical Memory  และ Machine Memory 

       หรือ ถ้าจะมองให้ง่ายขึ้นตามการใช้งาน

       หลายๆคนคงรู้จัก Virtual และ Physical memory เป็นอย่างดี  แต่ อะไรคือ  Machine memory ละ

       Machine memory คือ  memory ที่เครื่องใช้จริงๆ (Hardware)  หรือ Memory  ที่  ESXi  บริหารจัดการนั้นเอง เนื่องจาก  OS /VM  นั้นไม่มีสิทธิ์ในการจัดการ Memory  ดังนั้นการ allocate memory ให้กับ VM จึงเป็นหน้าที่ของ Hypervisor

            VM ที่รันอยู่บน Hypervisor (ESXi) นั้นก็เปรียบเสมือน Application ที่รันอยู่บน OS  นั่นเอง เพียง  แต่สำหรับ  VM นั้น จะเข้าใจว่าตัวเองนั้นถือครอง memory ทั้งหมดที่เห็น  (ที่เราconfigure ไว้ตอนที่สร้าง VM) โดยไม่รู้ตัวเลยว่า ตัวเองนั้น รันอยู่บน ESXi อีกทีหนึ่ง

         

            ดังนั้นปัญหาแรกที่เจอเลยคือ  ถ้าผมจะรัน VM  5 เครื่อง  โดยมี memory เครื่องละ 4 GB  ก็ต้องใช้ ESXi ที่มี memory ขั้นต่ำ 20 GB ซึ่งการจัดสรร memory แบบนี้นั้น ดูไม่ค่อยมีประสิทธิภาพเท่าไหร่  เนื่องจาก บาง VM อาจจะใช้จริงๆแค่ 2 GB เท่านั้น  แต่เราต้อง allocate ไปให้ทั้ง 4 GB

             ปัญหาที่สองต่อมาก็คือ  เวลาที่ OS  บน VM  มีการ free memory ขึ้นมา  อาทิเช่น  App ถูกปิดการใช้งานเป็นต้น   Hypervisor นั้นจะไม่รู้เลยว่า OS ได้ free memory  ในส่วนนั้นไปแล้ว  เนื่องจากในมุมมองของ Hypervisor   ไม่ได้รู้ว่า  App ไหนถูก close ไปบ้าง    ทำให้Hypervisorไม่สามารถเรียก memory ที่ free นั้นกลับมาใช้งานใหม่ได้   (memory ในส่วนที่ free  ก็ยังคงถูก OS จองไว้ )

            เพื่อจัดการกับปัญหาทั้งสองข้อข้างต้น     TPS  และ  Ballooning จึงถูกนำมาใช้งานเพื่อแก้ไขปัญหา ตามลำดับ

           

            TPS (Transparent page sharing) คือ การแชร์ memory ครับ   memory ในส่วนไหนซ้ำกัน แทนที่จะเก็บไว้ทั้งสองค่า  ก็จะยุบเหลือค่าเดียวเพื่อประหยัด memory    วิธีนี้จะทำให้เราสามารถใช้ memory ได้มากกว่าที่ควรจะเป็นได้ ดังนั้น จากเดิม  ESXi เรามี memory 20 GB รันได้ 5 VM  (VM ละ 4GB) เราอาจจะรันได้ 5-8 VM เลยทีเดียว  โดยทั้งนี้ขึ้นอยูกับว่า VM นั้นเป็น OS เดียวกันหรือไม่  ยิ่งถ้า patch ใกล้กันเท่าไหร่  ก็จะมีส่วนที่ซ้ำ ซึ่งสามารถนำมาแชร์ได้มากเท่านั้น

             เพิ่มเติมได้ที่นี่ Transparent Page Sharing

      

            Ballooning  คือวิธีการดึงmemory ในส่วนที่  OS จองไว้  แต่ไม่ได้มีการใช้งาน(Free)  นำกลับมาใช้งาน    

             

            โดยปกติแล้ว  Guest OS  นั้นจะไม่รู้สึกเลยว่าตัวเองนั้น โดน virtualize อยู่ ดังนั้นเมื่อเราทำการ Power On Guest OS  นั้นขึ้นมา   OS จะทำการกิน memory ไปเท่ากับที่เราคอนฟิกไว้  เนื่องจากคิดว่าตัวเองนั้นถือครอง  Hw ทั้งหมดเสมือน ว่ารันเป็นแบบ Physical machine  แต่ในความเป็นจริงแล้ว  Guest OS  นั้น ไม่ได้ใช้ memory ทั้งหมดเท่าที่ตัวเองกินไป  อาจจะใช้  memory ไปแค่ครึ่งเดียวเท่านั้น    

           หน้าที่ของ Ballooning  ก็คือการนำเอา memory ที่ Guest OS ไม่ได้ใช้นั้น ไปให้กับ  Guest OS ตัวอื่นๆที่ต้องการใช้  

           Q:แล้วเราจะสามารถนำ free memory ในส่วนนี้ไปใช้ได้อย่างไร  เนื่องจาก Guest OS  นั้นครองครองอยู่   ????

          VMware  ใช้หลักการง่ายๆครับ  โดยไปบีบให้ Guest OS นั้นคาย memory ที่ free นั้นออกมาเอง อาศัยหลักการของบอลลูน   คือตอนที่เราลง VMware tools   จะมี   balloon driver  ตัวนึงที่ติดลงไปด้วย

        Ballooning ---   Hypervisor(ESXi) จะสั่งให้ balloon driver  เริ่มกิน memory บน Guest ไปขนาดหนึ่ง ส่งผลให้ Guest นั้นต้องทำการ  allocate memory ให้กับ balloon driver   (ไม่ต้องห่วงครับ จะกินไม่เกิน 65% ของ Guest memory) หลังจากนั้น balloon driver  จะรายงานไปยัง ESXi  ถึง memory page ที่ตัวเองได้ครองครองไว้    ซึ่ง ESXi  จะนำmemory ในส่วนนี้  นำไปให้กับ  Guest อื่นๆ ต่อไป 

        Inflating    ---    จะตรงกันข้ามกับกระบวนการแรก  กล่าวคือ   balloon driver จะทำการคาย memory ออกไป เป็นการคืน memory กลับไปให้ Guest

        

      Note: 1. เนื่องจาก  memory ที่ balloon driver นั้นถือครองไปนั้น  Guest  จะไม่สามารถนำไปใช้งานอย่างอื่นได้  (โดน lock)  เราจึงสามารถนำ memory ในส่วนนี้ไปให้กับ Guest เครื่องอื่นๆได้

                2.  Ballooning นั้นไม่ได้ทำให้ Guest  เกิดการ  swapping เสมอไปนะครับ  หลายคนเข้าใจผิดในส่วนนี้   ผมขอยกตัวอย่างดังนี้   สมมติ Guest นั้นมี  free memory 2 GB  , balloon driver  กินmemory ไปเพียง 1 GB   Guest จะไม่ทำการ swap นะครับ  เนื่องจาก ยังมี memory เหลือใช้งานอีก 1 GB

แต่ถ้า balloon กินไป 2 GB  Guest จะเริ่มทำการ swap memory ในส่วนที่ไม่ active หรือไม่จำเป็นออกไปเก็บไว้บน disk   ซึ่ง balloon driver จะกิน memory มากหรือ น้อยนั้น ขึ้นอยู่กับว่า physical memory นั้นมีเหลือเพียงพอสำหรับ รัน VM หรือไม่   Balloon จะเป็นตัวบ่งบอกว่า Host ของคุณนั้น เริ่มมีการขาดแคลน memory   อาทิเช่น  รัน VM มากเกินไปกว่าที่ เครื่องจะรองรับได้

        Memory Compression  จะเกิดขึ้นหลังจากที่ ESXi  ได้ทำ  TPS และ Ballooning แล้ว แต่ระบบนั้นต้องการใช้ memory มากขึ้น  แต่ ESXi นั้นไม่มี memory เหลือพอให้ใช้แล้ว  ESXi จะเริ่มทำการ compress  memory page  เพื่อทำการ free memory   

หลักการคือ   ถ้าคำนวนแล้ว สามารถที่จะบีบอัดข้อมูลชุดนั้นๆได้ มากกว่าหรือเท่ากับ 50%  ระบบจะทำการบีบอัด memory page นั้นๆ   แต่ถ้าไม่ถึง  จะไม่ทำการบีบอัดครับ  ดังนั้นสำหรับ  memory page ขนาด 4KB   ถ้าบีบอัดแล้วลดลงได้เหลือ 2KB ระบบจะทำการบีบอัดทันที   

ดังนั้น 4KB   สองอัน ก็จะเหลือแค่ หนึ่งอัน  เราก็จะได้ memory free กลับมา 4KB

       Note:  การทำแบบนี้ส่งผลกระทบต่อ  performance แน่นอนครับ เพราะระบบจะต้องเสียเวลาในการ   compress / decompress memory   แต่ performance    ก็ยังดีกว่า การ swap ลง disk  อยู่ค่อนข้างมาก

       Hypervisor(Host) Swapping    อันนี้ตรงไปตรงมาครับ คือการ  swap memory  ลงไปยัง disk  หรือลงไปบน Datastore  นั่นเอง  ซึ่งจะได้ performance ที่ค่อนข้างแย่ 

      Note:  ถ้าลอง  Browse Datastore ดู จะเห็นไฟล์นามสกุล  .vswp  (swap ไฟล์ สำหรับแต่ละ VM )  ซึ่งจะมีขนาดเท่ากับ memory ที่เราคอนฟิกไว้ให้กับ Guest    แต่ ไฟล์นี้จะปรากฏขึ้นมาต่อเมื่อ  VM  power on   และจะหายไปเมื่อเรา power off เครื่อง  หลายคนลืมคิดถึงตรงนี้ส่งผลให้  Datastore ที่เก็บ VM นั้นเต็ม  คิดดูดีๆนะคับ  ถ้าเราคอนฟิก memory VM ไว้ 16 GB  swap ไฟล์ก็จะกินพื้นที่บน Datastore  ไป 16GB นะครับ  แล้วถ้าเกิดพื้นที่ไม่พอขึ้นมา  เราจะไม่สามารถเปิด VM  ขึ้นมาได้ เนื่องจากไม่มีพื้นที่พอที่จะสร้าง swap file ครับ  

     ในกรณีที่ มีการ reserve memory ไว้ให้กับ VM   ขนาดของ swap file = configure mem -mem reserve

      

      Swap to SSD (vSphere 5)  เป็นลูกเล่นใหม่ ที่นำมาใช้แก้ปัญหาของการ Swap to disk (Host swap)  โดยทำการ  swap ไปยัง SSD แทน ซึ่งมี speed , response time ที่ดีกว่า diskแบบหมุนมาก

       

        

   หวังว่าคงเข้าใจเรื่อง memory  มากขึ้นนะครับ  แล้วพบกันครับ

   

      

      

   

ESXi File Systems

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

     วันนี้ ผมอยากจะอธิบายเกี่ยวกับโครงสร้างของ ESXi นิดนึง  จิงๆเรื่องนี้ค่อนข้างใหญ่ทีเดียว  แต่ผมจะโฟกัสไปที่ file systems เป็นหลัก  ลองดูภาพข้างล่างนี้นะคับ

    ภาพนี้ผมนำมาจาก properties ของ storageที่ใช้ลงESXi  เราจะสังเกตุได้ว่า  Esxi นั้นจะมีทั้งหมด 8 partition ด้วยกัน (จิงๆคือ 4 primary partition เนื่องจากมี extended partition) แต่จากภาพ  เราไม่รู้เลยว่าแต่ละ partition นั้นใช้ทำหน้าที่อะไรกันบ้าง ดังนั้นผมจะลองขุดเพิ่มเติมโดยผมจะทำการ ssh เข้าไปที่ ESXi

    
จากภาพเราจะสามารถ map partition ไปยัง folder ที่ใช้งานได้โดยมีดังนี้  bootbank, altbootbank, scratch, store ..................... เออ  แล้วแต่ละ folder นั้นไว้ใช้เก็บอะไรละ?  ไว้ผมโชวให้ครบก่อนแล้วจะอธิบายให้นะคับ
เรามาขุดกันต่อดีกว่า   
           

    จากภาพจะเห็นได้ว่าทั้งสี่ partition ที่กล่าวมานั้นมาจาก disk ที่ชื่อ naa.600605b00151xxxxxxxx
 โดยถ้าเรานำไปโยงกับภาพก่อนหน้านี้เราจะได้ว่า scratch --->partition ID 2 , store -->partition ID 8, bootbank-->partition ID 5 ,altbootbank -->partition ID 6

    เอ.............. แล้ว partition ID 7 ไปอยู่ไหนละ  คำตอบคือ partition ที่ 7 นั้นคือ VMKcore (จากภาพแรกสุด) นั้นเอง เราสามารถดูได้จาก command  esxcfg-dumppart  ซึ่งจะโชว์ partition ที่ใช้สำหรับ dump memory ในกรณีที่เรื่องมีปัญหา
     
   สำหรับคนที่รู้linux อาจจะดูจาก command fdisk ได้เข้าใจง่ายกว่า ดังภาพข้างล่างนะคับ

         จะเห็นได้ว่า partition ที่ 3  type เป็น VMFS (Virtual Machine File Systems) ซึ่งก็คือ Local Datastore ของ ESXi นั้นเอง อีกจุดที่น่าสังเกตุคือ  Boot  *  หรือ  boot partition นั้นเอง
ตรงนี้ผมขอเตือนนะคับว่าเลข partition ที่เห็นจาก command นั้นไม่ได้เรียงในลำดับที่ถูกต้องนะคับ
อย่างเช่น boot partition นั้น ในที่นี้เห็นเป็น ID 4  แต่จิงๆแล้วคือ ID 1 เรารู้ได้จาก column start /end ซึ่งจะระบุุ block เริ่มต้นของ disk จาก 1 ไปถึง 286876672 

ปล.  partition ID 1 นั้น  type เป็น extended โดยเริ่มจาก block ที่ 5 ไปถึง block ที่ 900 นั่นหมายความว่า  partition ที่ 5-8 นั้นเป็น extended partition ที่มาจาก patition ที่ 1นะคับ

     จากที่เราได้ขุดมาดูทั้งหมดนั้น สามารถสรุปได้ดังนี้คับ

     

     เอาละมาเข้าเรื่องกันดีกว่า
     bootbank และ altbootbank นั้นจะใช้สำหรับเวลาอัพเกรด หรือ อัพpatch หลักการจะเหมือน dual boot firmware คับ โดย version ปัจจุบันที่ใช้ boot จะอยู่ที่ bootbank  ส่วนเวอชั่นใหม่นั้นจะลงไปที่ altbootbank   หลังจาก reboot ระบบจะทำการสลับ mount point ระหว่างทั้งสองอันนี้โดยเวอชั้นเก่าก็จะถูก mount ไปที่ altbootbank แทน(จะถูกลบไป  เมื่อเราทำการ upgrade,patch ครั้งถัดไป) ดังนั้นเมื่อเกิดอะไรขึ้น เราก็ยังจะสามารถถอยกลับไปยังเวอชั่นก่อนหน้านี้ได้ 1 level คับ
     store จะใช้เก็บไฟล์  Vmware tools สำหรับ Guest
     VMKcore ก็ใช้เป็นที่ รองรับ core dump
 
     ก่อนที่จะพุดถึง scratch   ผมขอชี้แจงนิดนึงเกี่ยวกับ ESXi ก่อน ไม่งั้นจะงงคับ
     Folder / (root) นั้นจะเป็น memory base นั่นคือ  file นั้นเก็บไว้บน memoryทาง VMware เรียก ESXi file systems ว่า visorfs (Hypervisor File Systems)  ดังนั้นถ้าเราreboot ข้อมูลใน / ก็จะหายไปด้วย โดยเฉพาะอย่างยิ่ง /var/log  ซึ่งใช้เก็บ log ทั้งหมด แต่ทำไมทุกครั้งที่เรา reboot ESXi คอนฟิคต่างๆไม่เห็นหายไปไหนเลย  นั่นก็เพราะว่าESXi จะทำการsave state ของตัวเองทุกๆชั่วโมง ไปเก็บไว้ที่ ไฟล์ /bootbank/state.tgz ซึ่งอย่างที่เรารู้กัน bootbank นั้นจะอยู่บน disk  แต่ๆๆๆๆๆๆๆๆๆๆๆๆๆๆๆๆ
ESXi ไม่ได้ save ทุกอย่างนะคับ โดยหลักๆจะsaveข้อมูล configure ใน folder /etc                     
ยังงี้ /var/log  log ผมก็หายหมดดิ ------------>  /scratch ก็มีไว้เพื่อการนี้และคับ
      scratch นั้น จะมีขนาด 4 GB จะเก็บไฟล์ที่ download มาบน ESXi , log และ /var/tmp  โดยถ้าตอนลง ESXi ระบบเห็นว่ามี disk อย่างต่ำ 5 GB  ระบบจะทำการสร้าง scratch ให้อัตโนมัติ
สามารถอ่านเพิ่มเติมได้ที่นี่คับ KB: 1033696

จากที่พูดมาทั้งหมดนะคับ
 1. เนื่องจากเก็บ folder / (root) เป็น ramdisk  ดังนั้นไม่ควรใช้เป็นที่เก็บไฟล์ที่ไม่จำเป็นคับ   ถ้าจะเก็บให้ไปใช้บน Datastore จะดีกว่า
2. อย่าหวังว่า ไฟล์ที่เก็บไว้บน / (root) จะทนการrebootได้นะคับ ESXi จะsave เฉพาะไฟล์ที่จะเป็นเท่านั้นคับ
 

VMware Fault Tolerance

สวัสดีคับ ช่วงนี้ผมได้เจอปัญหาเกี่ยวกับ Fault Tolerance หรือ ที่เราเรียกกัน FT ค่อนข้างเยอะ มีหลายๆคนยังคงสับสนระหว่าง FT กับ HA (High Availability) อีกทั้งยังไม่รู้ถึงปัจจัยต่างๆที่จะส่งผลกระทบต่อ performance ของ VM ที่ ใช้ FT งั้นจะขออธิบายคร่าวๆ เผื่อหลายๆคนที่ยังไม่เคลียร์ในเรื่องนี้นะครับ

FT ต่างกับ HA ตรงไหน ??
ในกรณีที่เครื่อง ESXi มีปัญหา เช่น ไฟดับ จะส่งผลให้ VM ทั้งหมดบนที่รันอยู่บน ESXi นั้นจะร่วงไปด้วย ,HA นั้นจะทำหน้าที่ power on เครื่อง VM ที่ดับไปนั้น ให้ไปรันอยู่บน ESXi เครื่องอื่นที่เหลืออยู่ใน Cluster (มี downtime )
สำหรับ VM ที่ทำ FT นั้นจะเหมือน การทำ clustering คับ โดยจะระบบจะสร้างเครื่อง secondary VM ขึ้นมา ดังนั้นถ้าเครื่อง primary ร่วงไป , เครื่อง secondary จะทำหน้าที่แทนทันที (ไม่มี downtime) โดยที่ทั้งสองเครื่องนี้ จะไม่มีทางรันอยู่บน ESXi(Host) เดียวกันเด็ดขาด


ข้อควรรู้เกี่ยวกับ FT
- การทำ FT นั้นไม่ต้องพึ่งพา software clustering ใดๆเลย
- Support single vCPu เท่านั้น สำหรับ support Multi processor นั้นขอให้รออีกนิดคับ ใกล้จะมาแล้ว
- CPU บางรุ่นเท่านั้นที่ support นะคับ อีกทั้งcpu เครื่องprimary,secondary ต้องอยู่ในกลุ่มเดียวกันถึงจะทำ FT ได้ โดยสามารถตรวจสอบได้จาก KB: 1008027
- OS ก็เช่นกัน ไม่ได้รองรับ OS ที่รุ่น โดยสามารถตรวจสอบได้จาก KB: 1008027

- สำหรับ version 4.0 ESX/ESXi ต้นทางและปลายทางต้องรัน version และ build number เดียวกัน
แต่สำหรับ version 4.1 ขอแค่ version FT เท่ากันก็เพียงพอคับ (สามารถดูได้จาก tab summary)
- ไม่สามารถทำ snapshot ขณะ ออน FT ได้ นั่นหมายถึง ไม่สามารถ backup ได้ด้วย vcb , vStorage API และไม่สามารถทำ storage vmotion ได้ด้วย
- CPU เครื่องprimary และ secondary ไม่ควรต่างกันเกิน 400MHz
- ไม่ควรรันเกิน 4 FT VM ต่อ 1 ESX/ESXi (จิงๆสามารถรันเกินได้นะคับ แต่ VMware ไม่แนะนำ)
- Nic ที่จะใช้ทำ FT logging ขั้นต่ำควรเป็น 1Gbps
-ไม่ support Thin-disk นะคับ
- VM ที่ทำ FT นั้น ,Memory reservation ของ VM (edit setting --->resource) จะถูกเซ็ตไว้ให้เป็นค่าเดียวกันจำนวน memory ที่เราเซ็ตไว้ตอนสร้าง VM นั้น พูดง่ายๆคือจองเมมไปใช้เต็มที่เลย
-เวลา enable FT นั้น ระบบจะทำการ copy memory เครื่อง primary ไปยังเครื่อง secondary โดยผ่านทาง feature vmotion ดังนั้น การ enable FT บ่อยๆนั้นอาจจะไม่เหมาะสมเท่าไหร่ ,process การ enable FT นั้นจะช้าหรือเร็ว จะขึ้นอยู่กับ speed ของ port vmotion และขนาดของ memory
-ควรจะ dedicate nic ให้กับการทำ FT logging เนื่องจาก network input (Rx) , disk read , user input ของเครื่อง primary นั้นจะถูกต่อส่งไปยังเครื่อง secondary โดยผ่านทาง nic นี้
-ในกรณีที่ เครื่อง primary VM ตายไป เครื่อง secondary จะทำหน้าที่เป็น primary แทน หลังจากนั้น ระบบจะทำการสร้างเครื่อง secondary ใหม่ขึ้นมาทันที โดย HA จะเป็นคนเลือกให้ว่าควรจะไปอยู่ที่ไหน แต่ที่แน่ๆไม่มีทางอยู่บน ESX/ESXi เดียวกับเครื่อง primary แน่ๆคับ โดยprocess นี้ระบบทำให้อัตโนมัติคับ
- ถ้าต้องการทำ load balance FT logging nic นั้น ----> KB: 1011966
-FT ไม่พึ่งพา vCenter จึงไม่ต้องห่วงกรณีที่ vCenter down ไป
-เราสามารถ vmotion ได้ทั้งเครื่อง primary และ secondary นะคับ
-เพื่อ balance network traffic ควร mix ระหว่าง primary และ secondary VM ของแต่ละระบบไว้ใน ESX/ESXi เดียวกัน เนื่องจาก network traffic ส่วนใหญ่นั้นจะวิ่งจาก primary -->secondary เป็นหลัก
-ถ้าเครื่อง secondary sync ตามเครื่อง primary ไม่ทัน จะทำให้ performance ของ VM นั้นตกลง เนื่องจาก เครื่อง Primary ต้องรอให้เครื่อง secondary ไล่ตามให้ทัน
- Vmware เรียก technology ในการ sync นี้ว่า vLockstep คิดซะว่าเหมือน เกียร์สองตัวเชื่อมด้วยสายพานเดียวกันคับ ถ้าตัวหน้าหมุนไป ตัวหลังก็ต้องหมุนตาม ถ้าตัวหลังหมุนช้าลง ก็จะทำให้ตัวหน้าช้าลงไปด้วย ยกตัวอย่างเช่น ESX/ESXi ที่ เครื่อง secondary อยุ่นั้น CPU ใช้งาน100% แต่ที่ ESX/ESXi ของเครื่อง primary นั้น CPU ใช้ไปแค่ 30%
จะส่งผลให้ เครื่อง secondary ไม่มีcpu resource เพียงพอที่จะไล่syncตามเครื่อง primary

หวังว่าที่กล่าวมาทั้งหมดนี้ คงช่วยตอบคำถามหลายๆคนได้นะคับ

Virtual Core in vSphere 5

ก่อนเวอชั่น vSphere 4.1 แอดมินไม่สามารถกำหนดจำนวน Core ให้กับ vCPU ของตนเองได้
ซึ่งโดยทั่วไปแล้ว (เวอร์ชั่นก่อนๆ)1 vCPU คือ 1 CPU socket สำหรับ Guest VM "ดังนั้น Windows 2003 Standard VM ก็จะใส่ได้แค่ 4 vCPU เนื่องจาก win standard support สูงสุดที่ 4 socket "

จากประโยคข้างบน หลายคนคงเริ่มบ่น เนื่องจากไม่คุ้มกับค่าlicenseอย่างมากกก เพราะถ้าเทียบกับการใช้งานบนเครื่อง physical เราสามารถใช้งาน CPUได้มากกว่า 4 โดยการซื้อ multi-core processor มาใช้งาน อาทิเช่น ใช้ 2 quad-core processor จะทำให้ Windows มองเห็นถึง 8 logical processor เลยทีเดียว
เพื่อแก้ปัญหาตรงนี้ ในเวอชั่น vSphere 4.1 จึงเพิ่ม feature ตรงนี้ขึ้นมา แต่จะต้องเข้าไปแก้ใน advance option ซึ่งบางคนอาจจะไม่ชอบใจนัก ดังนั้นใน vSphere 5 จึงมีเมนูให้กำหนด virtual core ให้ตั้งแต่แรก ดังรูป

ท้ายสุด หลายๆคนก็จะถามกลับมาว่า "ถ้างั้นระหว่าง 4 virtual socket / 1 virtual core กับ 2 virtual socket /2 virtual core ผมควรจะกำหนดอย่างไรดี เนื่องจากทั้งคู่ได้ผลลัพธ์เท่ากัน"
ผมแนะนำอย่างนี้คับ ถ้าไม่มีความจำเป็นหรือไม่ติดเรื่อง license ก็ให้ใช้ virtual core เป็น 1 ไปคับ แล้วเซ็ต virtual socket ตามความต้องการ จะเหมาะสมที่สุดคับ

VMFS5 versus VMFS3

วันนี้ผมมีโอกาสได้ลองเล่น VMFS 5 (VMware File System) ที่มากับ vSphere5
และพอดีไปเจอตารางเปรียบเทียบ ของทาง VMware มา เลยอยากจะเอามาแชร์ให้คับ

1.จะเห็นได้ว่า VMFS5 นั้นไม่มีลิมิตขนาดDatastore ไว้ที่ 2 TB อีกต่อไป เนื่องจากเปลี่ยนไปใช้ Partition Table แบบ GPT (เหมือนกับของ Windows 2008 )
2. จาก Block size 1,2,4,8 MB จะเหลือแค่ 1 MB
3. Sub-Block size จากเดิมที่เป็น 64K -----> 8K ทำให้ใช้พื้นที่disk ได้อย่างมีประสิทธิภาพมากขึ้น
4. การอัพเกรดจาก 3--->5 ไม่มี downtime คับ (อันนี้สำคัญที่สุด 55)

New snapshot menu in vSphere 5

วันนี้ผมจะมาขอแนะนำ  เมนู snapshot ที่เพิ่มเข้ามาใน version  5 นะคับ
คนที่ลองเล่น version 5 ไปแล้วอาจจะยังไม่สังเกตุเห็นก็ได้   ไม่พุดมากละคับ ดุรุปกันเลยดีกว่า

เอออ แล้วมันมีไว้ทำอะไรละเนี่ย
เมนูนี้ทำขึ้นมาเพื่อแก้ปัญหาที่ทำให้ adminหลายๆคนปวดหัวใน vsphere4  คับ
     ใน vSphere4  ถ้ากระบวนการ merge/delete snapshot fail ขึ้นมา สิ่งที่เกิดขึ้นก้คือ ไฟล์snapshot นั้นจะยังคงค้างอยู่ใน Datastore แต่ใน snapshot manager จะไม่โชว์เลยว่ามี snapshot ค้างอยู่ ซึ่งถ้าadmin ไม่เข้าไปดุที่ Datastore หรือ ดูผ่าน Storage View จะไม่มีทางรุ้เลย  ซึงการจะลบ snapshot ที่ค้างเหล่านี้ออกไปนั้น จะต้องทำโดยใช้ command line เท่านั้น ไม่สามารถทำผ่าน snapshot manager ได้
     ดังนั้นในvSphere เวอชั่น 5 นี้ จึงได้เพิ่มเมนู consolidate ขึ้นมาเพื่อแก้ปัญหาตรงจุดนี้ คับ  เราสามารถที่จะสั่ง merge snapshot ได้จากเมนูนี้เลย โดยไม่ต้องไปพึ่ง command line  แบบ version 4 อีก 

ชีวิตสบายขึ้นอีกเยอะ ^_^