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