Home / Chuyên đề tự học / Vmware Vsphere: Network trong ảo hóa vmware phần 3

Vmware Vsphere: Network trong ảo hóa vmware phần 3

Tuhocmang – Vmware Vsphere: Network trong ảo hóa vmware phần 3

Properties Vswich 0

Chon Vswitch -> Edit

Sẽ thấy 3 policy của Vswitch gồm: Security, Traffic Shaping, Nic teaming

Chọn port group cũng thấy 3 policy

Vậy 3 policy có thể apply lên Vswitch và Port group

Khi chỉnh trên Vswitch thì toàn bộ port group sẽ thừa kế policy Vswitch.

Nếu chỉnh lại trên port group thì những cái policy mà ta chỉnh trên port group sẽ được apply (dưới ưu tiên hơn).

Vào tab Security của Vswitch 0

Ở thực tế:Các switch có chức năng Security Port. Vậy nó để làm gì ??

Nhiệm vụ, chức năng của Security Port trên switch vật lý:

+ Không cho máy lạ kết nối vào hạ tầng vật lý (1)

+ Dễ monitor traffic (vì chỉ định MAC nào, port nào nên sẽ dễ dàng xử lý, monitor…) Khi gói tin tới, nhìn Mac để biết nó đi từ port nào (2)

Ảo hóa cũng giống vậy.

Switch ảo chỉ có máy ảo sử dụng (chỉ những máy ảo người quản trị cấu hình mới) => máy lạ không dùng được switch ảo => chức năng (1) không còn cần thiết => TH này không còn cần thiết

Nhưng ta sẽ có trường hợp Mac lạ xâm nhập vào Vswitch vì user  dùng máy ảo có thể change MAC (lúc này packet từ OS máy ảo bị change MAC).  Vswitch lúc này sẽ không biết vì Vswitch học MAC của máy ảo từ file vmx của máy ảo (lúc khởi động).

  • MAC lạ cũng xuất phát từ máy ảo => xét về độ bảo mật cũng không sao => MAC address change nên để Accept

Tại sao nên Accept ??
Vì khi chuyển từ máy thật sang máy ảo (P2V), có những phần mềm tính lisence theo MAC của card mạng => nếu đưa vào máy ảo thì MAC khác => mất license cần change lại MAC =>

MAC address change: Accept là cần thiết

 

MAC address change: cho phép nhận MAC lạ

Forged transmit: cho phép gởi MAC lạ. Cho phép chạy ra = MAC lạ. Chạy ra = MAC lạ thì gói tin  lúc nhận cũng là MAC lạ => cần phải cho phép nhận MAC lạ

2 cái này nên để đồng bộ

Promiscuous Mode:

Nếu để Accept: cho phép nhận dữ liệu từ các port khác trên vswitch.

Nếu để Reject: chỉ nhận dữ liệu từ gói tin tương ứng với MAC của nó (gửi cho nó thì nó nhận )

Không nên để accept vì bảo mật, đọc được traffic của các port group khác.

Khi nào để Accept: khi muốn monitor và phải làm ở cấp độ port group và những máy nào gắn trên port group này đều có khả năng monitor.

  • Cứ nên để default.

Tab Traffic Shaping:Policy này dùng để control bandwidth. Bình thường các Virtual Nic sẽ chạy với tốc độ unlimit.

MẶc định không control thì sẽ disable

Nếu muốn control bandwidth thì Enbale (đây là lí do ta tạo nhiều hơn 1 port group)

Ta có thể control trên conswitch hay trên port group tùy ý muốn.

Ôn lại: không tính đến phải chia Vlan. Thì trường  hợp nào cần nhiều port group ?. Đó là khi muốn control bandwich. Có 4 máy, muốn 2 máy bandwidth khác 2 máy còn lại thì tạo 2 port group cấu hình Shaping.

Có 3 mức độ control:

Average Bandwidth (Bandwdth trung bình): Ví dụ: cho 100000 kbit/s thì chạy trung bình là 10Mb/s. Khi ta chon VNic là e1000 có thể nhận max là 1Gb/S ta có thể dùng Average để control lại cho 100Mb/s thôi. Giá trị bandwidth thật có thể lệch so với Average

Beak Bandwitdh: giá trị Bandwidth max: có nghĩa là có thể cao hơn Average nhưng ko được vượt Beak

VD: cho Beak: 15000 kbit/s

Tao cho Average: 10M , Beak: 15M nhưng lỡ lúc nào nó cũng 12 13 cao hơn Average => không còn trung bình nữa, cần một con số quy định thời gian.

Burst size:  một khối lượng cao hơn ngưỡng trung bình trong một thời gian nào đó.

VD: ta chỉ muốn 120Mbit/s trong vòng 10 s thôi thì ta để Burst: 1200

Nếu lúc nào đó mà bandwidth của nó lúc 120 lúc 110 thì đương nhiên lúc này thời gian > Vaerage (100) sẽ kéo dài hơn 10 giây.

Như vậy: đơn vị của Burst: là Kbit Mbit Gbit

Cái này chỉ control đucợ chiều ra. (từ Vswitch đi ra ngoài)

Những Vnic nào nằm torng policy này sẹ bị apply như trên.

 

NIC Teaming: là policy quan trọng nhất. (NIC này là mặt luận lý, vật lý là NIC nhiều card thành 1 card luôn, có thể làm trên mainboard)

Khi nào dùng:

Như đã biết: 1 switch có thể map nhiều card mạng để tăng bandwidth, failover card.

Ta cần monitor xem các máy ảo có chạy đủ hay không

Sau khi gắn nhiều card vào thì ta phải chỉ cho Switch cách vận hành nhiều card.

Nic team có nhiều Mode

Load Balancing:

Gồm 3 policy con

Port ID:

VD: trường hợp 1 switch map 3 physical NIC

Khi bật máy ảo lên, Vnic sẽ đi tìm 1 physical Nic để hoạt động. Mặc định sẽ dùng phyNic đầu tiên.

Máy ảo 2 thì sẽ dùng PhyNic thứ 2.

Máy 3 sẽ dùng PhyNic 3.

Còn nếu co 4 máy dùng 2 PhyNic thì :

Máy ảo 1 dùng PhyNic 1
Máy ảo 2 dùng Phynic 2

Máy ảo 3 dùng PhyNic 1

Máy ảo 4 dùng Phynic 2

Kiểu như chia bài.

Và VNic sẽ nhận chết luôn ko thay đổi Phynic trừ khi PhyNic  fail. Nó sẽ phân lại.

Một máy sẽ chạy được tối đa 1 card. Đây là cách xử lý đơn giản nhất, không tốn tài nguyên

 

Source MAC  hash: Chia theo địa chỉ MAC

http://pubs.vmware.com/vsphere-60/index.jsp?topic=%2Fcom.vmware.vsphere.networking.doc%2FGUID-AB50CD25-4A34-4A07-9E48-0FBC49FA5884.html

Thay vì làm như Port ID

VD: ta có MAC của Vnic là F4-6D-04-0F-88-10

00:50:56:a3:c6:fb

Lấy byte cuối cùng chia (lấy dư) cho tổng số card (3 card)

0 (mod)3 = 0 => card đầu tiên

b (mod)3=2 => card thứ 3

 

Link hay: http://hostilecoding.blogspot.com/2013/10/vmware-mac-hash-based-lb.html

Như vậy chưa chắc sẽ đều. Xác xuất thôi.

Tại sao có cái này ?

Vì phiên bản ESX cũ.

Khi máy ảo có 2 VNic

Vnic 1 có Mac là xx:yy:zz:dd thì Vnic 2 sẽ có Mac là xx:yy:zz:dd+K (theo cấp số cộng)

  • Chọn Hash sẽ làm cho 2 Vnic kết nối với 2 PhyNic khác nhau . Nếu dùng Port ID sẽ có lúc bị trùng

Còn phiên ban mới thì random Mac với các Vnic  và chắc chắn rằng sẽ không bị trùng .

Quá trình  cũng gắn chết, tốn ít tài nguyên (ít dùng, thường dùng Port ID hơn MAC)

Hash này ko phải Hash như mình học mà kiểu như Mod

 

IP Hash: Khi máy ảo khởi động lên, khác với 2 TH đầu là chọn card luôn thì IP Hash không chọn card. Khi gởi dữ liệu ra thì Vswitch mới tính xem dùng PhyNIC nào để đi.

Vswitch sẽ lấy IP source XOR với IP đích. Sau đó lấy kết quả Mod (lấy dư) với tống số card

Lúc này: mỗi packet sẽ được tính => phức tạp, tốn nhiều tài nguyên nhưng rất hay. Vì lúc đó 1 máy ảo có thể chạy toàn bộ các Card (ưu điểm).

 

Vấn đề: so 2 người hợp trên, MAC của VNic sẽ chỉ đi đến 1 port  nhất định của Physical Switch.

  • Gói tin từ máy ảo ra trường nào sẽ vô lại bằng đường đó.

Còn IP hash: cùng Mac nhưng lúc thì  từ port này , lúc thì từ port kia

  • Nếu VM1 gửi 1 gói tin đến port A => PhySwitch học MAC VM1 : từ port A (gói 1)

VM1 gửi thêm gói tin đến port B => PhySwitch học lại: MAC VM1: từ port B (gói 2) (vì theo quy tắc của Physwich là nó sẽ học cái port mà thấy cái máy đó mới nhất)

Gói tin reply của gói 1 sẽ đi theo port B => Chia tải không tốt

Trường hợp  này PhySwitch cũng phải tính như trên (=> physwitch cũng phải hỗ trợ tính năng này, trên cisco gọi là Ether channel, trong tính năng này có 1 mode chạy như vsphere tính ngược lại ).

 

Failover order: Đơn giản, chỉ dùng 1 card, card nào chết thì dùng card còn lại => không load balancing gì cả.

Network failover detect: Khi ta chạy 3 card, khi chết 1 card thì phải gỡ ra khỏi NIC team chỉ chạy các card còn lại thôi. Nhưng vấn đề: phải chỉ cho hệ thống biết khi nào thằng card hư đó không nằm trong team nữa

Default chọn:

Link status only: card mất tín hiệu  (rút dây, đứt dây, card hư) là coi như rút ra khỏi team.

(xem card mạng có sang không)

Beacon Probing: khi nào dùng trường hợp này

Khi Vswitch  gắn 3 card, gắn vào 1 PhySwitch. Khi có 1 card hư thì gỡ ra để load balancing  trên các card còn lại.

Nhưng có TH 1 số hệ thống gắn 3 card phyNic ra 3 con Physiwtch => 3 con switch nối vào switch core (xem link dưới)

Mặc dù 3 PhyNic hoạt động tốt, uplink giữa PhyNic và Phy-Switch tốt nhưng lỡ 1 đường từ Phy-switch đến  Switch Core chết coi như cũng chả xài được gì.

Trong trường hợp này, khi mô hình có nhiều switch, muốn check cả bên ngoài. Ta dùng Beacon Probing. Nó sẽ thường xuyên gửi các gói tin broadcast (khoảng 10s) ra. Thì theo quy tắc, nó sẽ vòng lại. Nếu không nhận được broadcast từ uplink nào thì uplink đó hư.

Thông thường chỉ gắn 1 switch. Và gắn 1 switch thì không được chọn Beacon Probing.

 

FailBack: Khi card fail rồi (VD: chon link status: mất tín hiệu la gỡ ra khỏi team).  Ta phát hiện ra là lỏng dây, cắm lại. Nếu chọn Yes thì khi card up lại sẽ tự động cho vào Nic team cũ. Chọn No thì ngược lại. Nên chọn Yes

Notify Switch: VD: khi 1 card bị fail. VM phải chọn các card còn lại. Vậy khi card up lại thì lại load balancing lại, VM lại quay lại card cũ (load balancing lại)

Đặt trường hợp 1 switch.

VM1 dùng card 1, phy-switch học Mac từ port 1. Card 1 hư VM1 chuyển sang card 2 , physwitch phải hoc Mac. Rồi nếu card 2 up thì VM về card1. Chức năng Notify Switch khi VM đổi chỗ thì Vswitch sẽ lấy Mac  send ra ngoài cho PhySwitch biết  để đổi

Nên để Yes.

Phần cuối ta thấy có 3 loại card

Active Adapters: bình thường, những card đưa vào Switch sẽ nằm torng Active.

Nếu ta có nhu cầu: Map 4 physical Nic vào 1 vswitch mà chỉ cho dùng 3 card. Thì ta cho card còn lại Standby. Bất kì thằng nào trong 3 thằng trên chết thì thằng StandBy sẽ lên thế.

Unused Adapters: Card sẽ dùng để dành, không làm dự phòng, không gì hết.

 

Khi làm Nic Team. Tất cả phải dựa vào Active để làm team. Nếu đẩy xuống dưới (standby, Unused thì khồng còn trong tema nữa).

Nếu hạ tầng bình thường: cứ chọn default. (loadbalacing: port ID, Link status v..vv). Nếu máy mạnh, hệ thống tốt chuyền Loadbalacing  thành chế độ IP Hash.

Nếu ESX chỉ gắn vào 1 phySwitch: chọn Link status, còn lai default.

Link tham khảo:

http:/buildvirtual.net/nic-teaming-failover-types-and-related-physical-network-settings/

http://theithollow.com/2012/03/understanding-beacon-probing/

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2006129

http://morgster79.blogspot.com/2012/05/ip-hash-load-balancing-setup-for.html

 

About Hoang Do Viet

Tớ thích thể thao, văn thơ, ghét IT như quỷ ý ......

Check Also

Vmware Vsphere: Network trong ảo hóa vmware phần 2

Tuhocmang.com – VMware Vsphere –  Network trong ảo hóa vmware phần 2 Ôn lại Network trong …

Virtual Switch VMware

Vmware Vsphere: Network trong ảo hóa vmware

Tuhocmang – Vmware – Vmware Vsphere: Network trong ảo hóa vmware (Phần 1) Network Trước ảo …

Leave a Reply

Your email address will not be published. Required fields are marked *