Windows 2012 Hyper-V 3.0 Network Virtualization (ตอนที่ 3)

กลับมาตามคำสัญญากับ Blog Series หนังเรื่องยาวกับ Hyper-V 3.0 Network VIrtualization จากความเดิมตอนที่แล้ว (ตอนที่ 2) หรือถ้าท่านผู้อ่านท่านใดอยากประติดประต่อเรื่องราวตั้งแต่แรกๆ เลยก็ตามไปอ่านได้ที่ตอนแรกได้ครับ (ตอนที่ 1)

ความเดิมตอนที่ 2
จาก diagram ที่ได้เตรียมขึ้นมาสำหรับทดสอบเรื่อง Hyper-V Network Virtualization ผมได้ทำการ เตรียม Hyper-V Host ด้านซ้ายมือและสร้าง VM ขึ้นมาทั้ง 2 เครื่อง (CustomerA-VM1 , CustomerB-VM1) และได้ทำการ config VirtualSubnetID ทั้ง 2 VM ให้อยู่กันคนละ VirsualSubnetID (เสมือนอยู่คนละ VLAN) เพื่อให้ VM ทั้งสองเครื่องใช้ IP Address 192.168.1.50 เหมือนกันได้โดยที่ ip address ไม่ชนกัน โดยผมเพิ่มข้อมูลในภาพให้เข้าใจง่ายขึ้นโดย CustomerA-VM1 คือสีน้ำเงิน (Blue network) และ CustomerB-VM1 คือสีแดง (Red network)   (อย่าพาเข้าการเมืองนะ เดียวยาวววว)
โดย
CustomerA-VM1 - Blue Network “VirtualSubnetID” = 54321

CustomerB-VM1 - Red Network “VirtualSubnetID” = 12345


เมื่อมองจากการ config เราจะได้ diagram บน Host1(172.16.1.1/16) ประมาณนี้ครับ


หลังจากนั้นผมมี Host2(172.16.1.2/16) เพิ่มมาอีกหนึ่งเครื่องผมก็ทำการ Config VirtualSubnetID ดังนี้
CustomerA-VM2 – Blue Network “VirtualSubnetID” = 54321
CustomerB-VM2 – Red Network “VirtualSubnetID” = 12345
ภาพ diagram ก็จะออกมาประมาณนี้ครับ

จากนั้นครับมาดูวิธีการที่จะทำให้ CustomerA-VM1 สามารถติดต่อกับ CustomerA-VM2 หรือ CustomerB-VM1 สามารถติดต่อกับ CustomerB-VM2 โดยใช้วิธีการของ NVGRE ต้องทำอย่างไร

Host1(172.16.1.1/16)
 ขั้นตอนที่ 1 - Enable ComponentID ms_netwnv บน Host1 เพื่อใช้งาน Network Virtualization

NIC ของ Host1 ก็พร้อมรองรับ Network Virtualization แล้วครับ

ขั้นตอนที่ 2 – สร้าง ProviderAddress (PA)

ขั้นตอนที่ 3 – สร้าง RoutingDomainID สำหรับ “VirtualSubnetID” 54321 (สำหรับ VM ของ CustomerA ติดต่อกันได้) และ “VirtualSubnetID” 12345 (สำหรับ VM ของ CustomerB ติดต่อกันได้)
โดยข้อกำหนดของ RoutingDomainID คือต้องไม่ซ้ำกันครับดังนั้น วิธีการสร้าง RoutingDomainID ผมใช้ function [System.guid]::newguid() ในการ random GUID เพื่อนำไปใช้เป็นค่า RoutingDomainID
โดยผมกำหนดตัวแปร $CustAGUID = [System.guid]::newguid()  ตัวแปร $CustAGUID ก็จะได้ค่า GUID random มาค่าหนึ่ง จากนั้นค่า GUID ที่ได้จะต้องอยู่ภายใต้เครื่องหมาย “{GUID}”  ซึ่งค่าที่ random GUID มามันจะเป็นตัวเลย GUID เฉยๆ ไม่มีเครื่องหมาย “{ }” มาให้ก็ต้องทำให้อยู่ภายใต้เครื่องหมายปีกกาให้ได้โดยใช้วิธีนี้

$CustAGUID = [System.guid]::newguid() 
$CustAGUID= “{“ + [String]$CustAGUID + “}”   เราก็จะได้ GUID ภายใต้เครื่องหมาย {}
เมื่อได้ RoutingDomainID ของ CustomerA แล้วเราก็จะสร้าง ProviderAddress (PA) ด้วย powershell ตามนี้
[PS] New-NetVirtualizationCustomerRoute -RoutingDomainID $CustAGUID -VirtualSubnetID 54321 -DestinationPrefix "192.168.1.0/24" -NextHop 0.0.0.0 -Metric 255
สร้าง RoutingDomainID ของ CustomerB
$CustBGUID = [System.guid]::newguid() 
$CustBGUID= “{“ + [String]$CustBGUID + “}” 
เมื่อได้ RoutingDomainID ของ CustomerB แล้วเราก็จะสร้าง ProviderAddress (PA) ด้วย powershell ตามนี้
[PS] New-NetVirtualizationCustomerRoute -RoutingDomainID $CustBGUID -VirtualSubnetID 12345 -DestinationPrefix "192.168.1.0/24" -NextHop 0.0.0.0 -Metric 255
ผลลัพธ์จากการสร้าง RoutingDomainID ของ CustomerA และ CustomerB จะออกมาหน้าตาประมาณนี้



ขั้นตอนที่ 4 – สร้าง Lookup Table (เสมือน routing table)
เมื่อเราสร้าง RoutingDomainID แล้วเราต้องมากำหนด Lookkup Table เพื่อบอกเส้นทางของ network flow ว่าจะวิ่งอะไรยังไงโดยวิธีการสร้าง lookup table ต่อไปนี้คือการ map 1:1
CustomerA-VM1 - Lookup Table
New-NetVirtualizationLookupRecord -VMName CustomerA-VM1 -VirtualSubnetID 54321 -CustomerAddress 192.168.1.50 -MACAddress 00155D00720C -ProviderAddress 172.16.1.1 -Rule TranslationMethodEncap -CustomerID $CustAGUID
CustomerB-VM1 - Lookup Table
New-NetVirtualizationLookupRecord -VMName CustomerB-VM1 -VirtualSubnetID 12345 -CustomerAddress 192.168.1.50 -MACAddress 00155D00720D -ProviderAddress 172.16.1.1 -Rule TranslationMethodEncap -CustomerID $CustBGUID
CustomerA-VM2 - Lookup Table
New-NetVirtualizationLookupRecord -VMName CustomerA-VM2 -VirtualSubnetID 54321 -CustomerAddress 192.168.1.51 -MACAddress 00155D006C03 -ProviderAddress 172.16.1.2 -Rule TranslationMethodEncap -CustomerID $CustAGUID
CustomerB-VM2 - Lookup Table
New-NetVirtualizationLookupRecord -VMName CustomerB-VM2 -VirtualSubnetID 12345 -CustomerAddress 192.168.1.51 -MACAddress 00155D006C04 -ProviderAddress 172.16.1.2 -Rule TranslationMethodEncap -CustomerID $CustBGUID
หน้าตาจะออกมาประมาณนี้


ที่นี้เมื่อมาลองพิจารณาตั้งแต่ขั้นตอนที่ 1 – 4 ที่ผมทำบนเครื่อง Host1 ถ้าลองมาเขียนตารางให้เข้าใจยากหรือง่ายแล้วแต่บุญบารมีของแต่ละคนแล้วละครับ ใครเห็นตารางแล้วเข้าใจก็อาจจะง่ายแต่ถ้าเห็นตารางแล้วบอกว่ายาก แปลว่าท่านต้องขยันทำการบ้านเยอะๆ ครับ


จากตารางผมทำขึ้นมาให้เห็น Traffic flow ที่เกิดจาก VM บน Host1 วิ่งไปติดต่อกับ VM บน Host2 ทางเดียวครับ ในความเป็นจริงต้องสามารถไปและกลับได้ครับ

ถัดมาครับมาดู config บนฝั่ง Host2 กันบ้าง
Host2
ขั้นตอนที่ 1 – กำหนด VirtualSubnetID ของ CustomerA-VM2 , CustomerB-VM2 ให้เหมือนกันกับ VM บน Host1

จะเห็นว่าถ้าเรา fix ip  192.168.1.51 ทั้ง 2 VM จะเกิดเหตุการณ์ ip conflict เหมือนกันครับแต่หลังจากเรากำหนด virtualsubnetID ไปแล้วก็จะไม่เกิดเหตุการณ์ ip conflict แล้วครับ
ขั้นตอนที่ 2 – Create RoutingDomainID

ขั้นตอนที่ 3 – Create Lookup Table

ขั้นตอนที่ 4 – enable Component ms_netwnv บนเครื่อง Host2


เสร็จแล้วครับ ไหนท่านผู้อ่านลองทดสอบ ping จากเครื่อง CustomerA-VM1 ไปยัง CustomerA-VM2 ให้ผมหน่อยครับว่า ping เจอไหมครับ
………..?????
ลืมไปงั้นผมทดสอบ ping ให้ครับผลเป็นไงลองดูเองละกันครับ

Ping จาก CustomerA-VM1(Host1) –> CustomerA-VM2 (Host2)


Ping จาก CustomerA-VM2(Host2) –> CustomerA-VM1(Host1)


Ping จาก CustomerB-VM1(Host1) –> CustomerB-VM2(Host2)



Ping จาก CustomerB-VM2(Host2) –> CustomerB-VM1(Host1)


จบครับ จบขั้นตอนวิธีการของ NVGRE ครับ
แต่มีคนสงสัยเหมือนผมไหมครับว่า VM บน Host ต่างเครื่องสามารถติดต่อกับ VM ต่าง Host กันโดยเสมือนมันอยู่ใน VLAN เดียวกันได้ก็จริง แต่ถ้ามองจากการใช้งานจริง Server – Server มีที่ไหนทำไหมครับ มันต้องมี client ไปผสมโรงด้วยถูกไหมครับ มันถึงจะครบองค์ประชุมครับ แต่เราจะทำอย่างไร เพราะใน diagram เอง client มันไม่ได้อยู่บน Layer Hypervisor แล้ว traffic จาก client จะวิ่งเข้าไปยัง RoutingDomainID เดียวกันกับ VM ได้อย่างไร โปรดติดตามตอนต่อไปครับ

และนอกจากสิ่งที่ผมเขียนอธิบายการทำงานของ NVGRE ให้เห็นวิธีการ config แล้วจะเห็นว่านี้ขนาดเรามี VM บน Host แค่ Host ละ 2 VM เท่านั้นเอง วิธีการ Config ยังยุ่งยากวุ่นวายขนาดนี้ถ้า Host หนึ่งเองมีสัก 100 VMs เกิดอะไรขึ้นนั่งพิมพ์ command กันมือหงิกแน่ๆ ถึงขนาดบ้างคนพิมพ์สัมผัสไม่ได้ก็คงเป็นกันงานนี้แน่ๆ Microsoft เองมี Product ตัวหนึ่งชื่อว่า System Center Virtual Machine Manager 2012 SP1 ใหม่ล่าสุด ที่ออกมากำราบจักรกลเสมือนของ microsoft ให้ว่านอนสอนง่ายเหมือนลุกไก่ในกำมือครับ นี้ก็จะเป็นอีกหนึ่ง Series ที่ผมกำลังจัดเตรียมเนื้อหาและบทความอยู่ครับ ถ้าพร้อมเมื่อไหร่จะมาอับเดตบนหน้า blog system center fast serv ของผมอีกทีครับ

สำหรับบทความตอนนี้ก็ขอจากกันไปก่อนนะครับ   …..ผมเข้าสู่โลกของจักรกลเสมือนแล้ว
แล้วคุณๆ เข้าสู่โลกจักรกลเสมือนเหมือนผมแล้วหรือยังครับ

Windows 2012 Hyper-V 3.0 Network Virtualization (ตอนที่ 2)

 

แท่นแท๊น กลับมาแล้วครับ Network Virtualization บน Hyper-V 3.0 ตอนที่ 2 ที่จากตอนเดิมที่แล้วผมได้เกิ่นไว้คราวๆ ว่า network virtualization คืออะไร ไอเดียและ concept เป็นแบบไหน ที่นี้ลองมาดูตัวอย่างที่อธิบายการทำงานทางด้านเทคนิคกันบ้างครับ

ข้อมูลจาก Technet

“A new feature in Hyper-v 3.0 is network virtualization which allow hosting providers to host VMs from different customer that can have the same IP address schema without the need to change their IP address or facing any IP conflict errors. Hyper-v provide two method to achieve this :

• IP packet encapsulation protocol Generic Routing Encapsulation (GRE), that encapsulate VM traffic into hyper-v traffic and use the host IP to deliver the encapsulated traffic to its destination hosting hyper-v.
• IP Rewrite : is Kind of Static Nat configuration where each VM IP address get rewritten using physical  IP address before it is transferred on the physical network.

วิธีการทดสอบที่จะเห็นต่อไปนี้ผมเลือกใช้วิธีการ GRE มานำเสนอให้ดูก่อนครับว่าวิธีการทำงานเป็นอย่างไร ok งั้นมาเริ่มกันเลยดีกว่าครับ ใครคันไม้คันมืออยากจะลองทำดูก็ลองๆ หา resource ตาม diagram ที่ผมเตรียมมาลองดูนะครับ

รูป diagram ที่เตรียมทำ LAB ในครั้งนี้

โดย LAB ที่ทางผมจัดเตรียมขึ้นมาก็ไม่มีอะไรมากครับ หาเครื่อง Host (Physical) สองเครื่องโดยเครื่อง Host มี card lan แค่ใบเดียวครับจากนั้นติดตั้ง Windows Server 2012 + Enable Hyper-V Role ไว้ครับ

 

รูป physical card lan จริงมี 1 port ก่อนเริ่มสร้าง virtual switch

จากนั้นบน Hyper-V ให้เราทำการสร้าง Virtual Switch (Type: External network: binding เข้ากับ card lan เครื่อง และติ๊ก option: allow management operating system to share this network adapter) ขึ้นมาหนึ่ง virtual switch

 

รูป การสร้าง External virtual switch สำหรับ VM และ Host ใช้งานแชร์ร่วมกัน

หลังจากสร้าง virtual switch แล้วเมื่อเรากลับไปดูใน network and sharing center เราจะเห็น card lan เพิ่มมาอีก 1 ใบครับ

 

และทำการเตรียมเครื่อง VM ขึ้นมาสองเครื่อง โดยจำลองว่า VM สองเครื่องนี้เป็นของลูกค้าเราคนละเจ้า ที่เข้ามาใช้บริการ Host ของเรา (ไม่ต้องไปสนใจ 3 VM ข้างล่างนะครับอันนั้นเตรียมไว้เขียน blog เรื่อง SQL 2012 Always On)

 

ที่นี้เราได้ environment ที่พร้อมจะทดสอบการทำงานของ Network Virtualization บน Windows 2012 hyper-V 3.0 แล้ว ถัดมาครับ ผมตั้งสถานะการณ์จำลองว่า VM ของลูกค้าทั้งสองเจ้านี้ fix ip เป็นเบอร์เดียวกันครับ

ลองคิดตามนะครับ ปกติเครื่องที่เชื่อมต่ออยู่บน switch ตัวเดียวกันไม่ได้แบ่ง VLAN ถ้าคุณใช้ ip address เบอร์เดียวกันจะเกิดอะไรขึ้นครับ……

แน่นอนครับ ip conflict กัน…..แล้ววิธีป้องกันหรือแก้ไขเพื่อไม่ให้ ip ของสองเครื่องนี้ชนกันทำอย่างไร? ก็กำหนดให้สองเครื่องอยู่กันคนละ VLAN สิ ip address เหมือนกันก็จะไม่ชนกันแล้ว !!! ถูกครับไม่ชนกัน แต่จะทำแบบนั้นได้ switch เองก็ต้องรองรับการแบ่ง VLAN

แล้วถ้า switch ไม่ support VLAN จะทำอย่างไรดีครับ? (คงไม่มีใครตอบว่าให้ถอดสายแลนเครื่องใดเครื่องหนึ่งออกก็สิ้นเรื่องนะครับ 555) ละไว้ในฐานที่เข้าใจของ network admin ที่หาทางออกได้ส่วนใครหาทางออกไม่ได้ลองดู idea network virtualize ดูก่อนไหมครับ เผื่อว่าจะคิดอะไรออกบ้าง

 

มาเข้าเรื่องของ LAB กันดีกว่า

CustomerA-VM1 ผมกำหนดให้ ip address 192.168.1.50/24

ลองดู ip address ของ CustomerA-VM1 ก่อนจะ fix ip จะเห็นว่า ip เป็น APIPA ip อยู่

 

หลังจาก fix ip

เช็ค ip address ด้วย powershell

 

เครื่องแรกผ่านไป มาที่เครื่องที่สองบ้างครับ

CustomerB-VM1 ผมกำหนดให้ ip address 192.168.1.50/24 เหมือนกันจะเกิดอะไรขึ้น!

ก่อน fix ip

หลังจาก fix ip แล้ว (powershell ยังไม่บ่งบอกว่า ip conflict)

แต่ถ้าเราไปรัน ipconfig /all ที่เครื่อง CustomerB-VM1 จะเห็นฟ้องว่า ip duplicate!!

สาเหตุที่ CustomerB-VM1 ip conflict กันเพราะว่าต่ออยู่บน virtual switch เดียวกัน (มองเหมือนต่ออยู่บน physical switch เดียวกัน) เมื่อ fix ip เหมือนกับตัวแรกทำให้เครื่อง CustomerB-VM1 โชว์ข้อความว่า duplicate

แต่ถ้าเราลองเข้าไปดูข้อมูลลึกลงไปอีกจะเห็นว่า VM ทั้งสองเครื่องต่ออยู่บน virtual switch เดียวกันถ้าอยากให้ใช้งานได้โดยเสมือนว่าเราแบ่ง VLAN ให้กับ VM ทั้งสองก็สามารถทำได้ครับ ( default ก็เหมือนกับ switch ทั่วไปที่ VLAN ID = 0 หรือ 1)

ที่นี้เราพอรู้แล้วว่าบน virtual switch ของ Hyper-V เราสามารถทำการแบ่ง VLAN (Private VLAN บน Hyper-V หรือเขียนย่อๆ ว่า PVLAN) ให้กับ VM ที่เชื่อมต่ออยู่บน virtual switch เดียวกันเพื่อให้ VM ที่มี ip address เดียวกันสามารถที่จะทำงานภายใต้ Host เดียวกัน และ virtual switch เดียวกันได้

มาดูวิธีทำกันดีกว่า

ที่เครื่อง CustomerB-VM1 ผมจะกำหนดให้อยู่ VLAN คนละ ID กับ CustomerA-VM1 โดยใช้ powershell command กำหนดค่า VirtualSubnetId ลงไป

เพียงเท่านี้ VM สองเครื่องก็จะสามารถทำงานอยู่บน Host เดียวกัน virtual switch เดียวกันโดยที่ใช้ ip address เหมือนกันด้วยครับ  (ขาดอะไรที่ยังไม่เหมือนกันอีกไหม)

ก็ขอจบบทความนี้ไว้เพียงเท่านี้ก่อนนะครับ เดียวมีตอนที่ 3 ต่อนะครับผม ในเวลาอันเร็วไวนี้แน่นอนครับ เพราะที่ผมแสดงให้เห็นข้างบนที่ผ่านมายังไม่ได้เข้าถึงเรื่อง GRE เลยสักกะติ๊ดเดียวครับ อันนี้แค่น้ำจิ้มๆ เรื่อง Private VLAN แค่นั้นเองครับ

ไว้ติดตามตอนที่ 3 ต่อไปนะครับ ขอไปหาเครื่องมาเทสก่อนครับผมมมม…