Service Classification, Visualization and Definition

Read More

Đánh giá mức độ ưu tiên Sự Cố

Hướng dẫn đánh giá mức độ ưu tiên Sự Cố mô tả các quy tắc để đánh giá và gán độ ưu tiên cho các Sự Cố phát sinh, bao gồm cả các tiêu chí để xếp một Sự Cố vào loại Sự Cố Nghiêm Trọng. Các quy tắc trong quy trình xử lý Sự Cố được xây dựng dựa trên mức độ ưu tiên của các Sự Cố, do đó việc gán độ ưu tiên một cách chính xác là yếu tố trọng yếu để kích hoạt một quy trình xử lý sự cố phù hợp.

Mức độ ưu tiên của một sự cố thường được xác định bởi 02 yếu tố : Tính khẩn cấp và mức độ ảnh hưởng, trong đó :

• Tính khẩn cấp mô tả mức độ cấp thiết mà một Sự Cố cần được giải quyết, theo như SLA đã cam kết với khách hàng.
• Mức độ ảnh hưởng mô tả những thiệt hại mà Sự Cố gây ra trước khi Sự Cố được giải quyết.

Tính khẩn cấp (Phân loại mức khẩn cấp)

Tính khẩn cấp của Sự Cố bao gồm nhiều yếu tố, trong đó mức độ khẩn cấp của Sự Cố sẽ bằng với mức độ khẩn cấp cao nhất của các yếu tố cấu thành, theo như bảng sau

Mức độ	Mô tả
Cao (H)	Mức độ thiệt hại do Sự Cố gây ra tăng rất nhanh theo thời gian. Thời gian càng dài, mức độ thiệt hại càng trầm trọng tăng càng nhanh. Do Sự Cố nên nhân viên không thể thực hiện được một số đầu mục công việc, và các công việc này có mức độ quan trọng và thiết yếu cao Một sự cố nhỏ có thể ngăn chặn để trở thành một Sự Cố nghiêm trọng nếu nó được xử lý ngay lập tức. Sự cố có ảnh hưởng đến các nhân vật lãnh đạo cao cấp trong doanh nghiệp / khách hàng.
Trung bình (M)	Mức độ thiệt hại do Sự Cố gây ra tăng một cách vừa phải theo thời gian. Sự cố chỉ ảnh hưởng đến 1 nhân vật quan trọng / lãnh đạo trong doanh nghiệp / khách hàng.
Thấp (L)	Mức độ thiệt hại do Sự Cố gây ra tăng không đáng kể theo thời gian. Các công việc mà nhân viên không thể hoàn thành do Sự Cố phát sinh không quá quan trọng hoặc cấp thiết.

Ví dụ một Sự Cố có mức độ thiệt hại tăng không đáng kể theo thời gian (mức Thấp) nhưng lại ảnh hưởng đến nhiều lãnh đạo cao cấp của doanh nghiệp (mức Cao) thì sẽ được phân loại mức độ khẩn cấp là Cao.

Mức độ ảnh hưởng (Phân loại mức độ ảnh hưởng)

Mức độ ảnh hưởng của Sự Cố bao gồm nhiều yếu tố, trong đó mức độ ảnh hưởng của Sự Cố sẽ bằng với mức độ ảnh hưởng cao nhất của các yếu tố cấu thành, theo như bảng sau

Mức độ	Mô tả
Cao (H)	Số lượng nhân viên và đầu mục công việc bị ảnh hưởng bởi Sự Cố lớn. Lượng khách hàng bị ảnh hưởng bởi Sự Cố lớn. Mất mát về mặt tài chính do Sự Cố gây ra có khả năng vượt quá $10,000 Mức độ ảnh hưởng đến danh tiếng và hình ảnh của hoạt động kinh doanh / doanh nghiệp lớn. Có người bị chấn thương / tổn thương về mặt vật lý bởi Sự Cố
Trung bình (M)	Số lượng nhân viên và đầu mục công việc bị ảnh hưởng bởi Sự Cố ở mức vừa phải. Lượng khách hàng bị ảnh hưởng bởi Sự Cố ở mức vừa phải. Mất mát về mặt tài chính do Sự Cố gây ra nằm trong khoảng $1,000 đến $10,000 Ảnh hưởng đến danh tiếng và hình ảnh của hoạt động kinh doanh / doanh nghiệp ở mức vừa phải.
Thấp (L)	Số lượng nhân viên và đầu mục công việc bị ảnh hưởng bởi Sự Cố ở mức thấp. Lượng khách hàng bị ảnh hưởng bởi Sự Cố ở mức thấp. Mất mát về mặt tài chính do Sự Cố gây ra nhiều khả năng nhỏ hơn $1,000 Ảnh hưởng đến danh tiếng và hình ảnh của hoạt động kinh doanh / doanh nghiệp ở mức thấp.

Phân lớp mức độ ưu tiên của Sự Cố

Mức độ ưu tiên của Sự Cố phụ thuộc vào tính khẩn cấp và mức ảnh hưởng của Sự Cố.

Ma trận độ ưu tiên

		Ảnh hưởng
		H	M	N
Khẩn cấp	H	1	2	3
	M	2	3	4
	L	3	4	5

Mã ưu tiên	Mô tả	Thời gian phản hồi Sự Cố	Thời gian giải quyết Sự Cố
1	Khẩn Cấp (Critical)	Ngay Lập Tức	1 Giờ
2	Cao (High)	10 Phút	4 Giờ
3	Trung Bình (Medium)	1 Giờ	8 Giờ
4	Thấp (Low)	4 Giờ	24 Giờ
5	Rất Thấp (Very low)	1 Ngày	1 Tuần

 

Sự Cố Nghiêm Trọng

Sự Cố nghiêm trọng dẫn tới sự thành lập tạm thời của Đội Xử Lý Sự Cố Nghiệm Trọng và được quản lý thông qua quy trình Xử Lý Sự Cố Nghiêm Trọng.

Dấu hiệu

Sự Cố Nghiêm Trọng, ngoài ma trận độ ưu tiên ở trên, cần được xác định thông qua một số dấu hiệu và chỉ báo cụ thể khác. Ví dụ :

1. Một số (nhóm) các dịch vụ, ứng dụng thiết yếu hoặc các thành phần của hạ tầng công nghệ thông tin rơi vào trạng thái không hoạt động (không sẵn sàng) và thời gian dự kiến để khắc phục chưa được xác định hoặc rất lâu.
2. Một số (nhóm) chức năng thiết yếu cho hoạt động sản xuất kinh doanh (các quy trình thiết yếu cho hoạt động sản xuất kinh doanh) bị ảnh hưởng và thời gian dự kiến để khôi phục hoạt động của các chức năng, quy trình này là chưa xác định hoặc rất lâu.

Nhận diện Sự Cố Nghiêm Trọng

Để có được một bản hướng dẫn chi tiết, cụ thể và chính xác về việc làm thế nào để xác định và nhận diện các Sự Cố Nghiêm Trọng là điều không dễ dàng, dù rằng đội hỗ trợ xử lý cấp 1 (1st Level Support) thường sử dụng "giác quan thứ sáu" của mình để thực thi việc nhận diện này !!!

 

Một Sự Cố Nghiêm trọng thường được nhận diện bởi mức độ ảnh hưởng của nó, đặc biệt là đối với khách hàng.

Ví dụ :

• Kết nối mạng tốc độ cao bị đứt, một phần hoặc toàn bộ đường truyền để liên lạc với hệ thống mạng ngoại vi không hoạt động.
• Không thể truy cập website để hoàn thành công việc khi sắp đến hạn. Ví dụ thời gian mở khuyến mãi bán vé máy bay online giá rẻ của Vietjet Air từ 8h đến 9h và chỉ có rất ít khách hàng có thể truy cập website trong khoảng thời gian này do số lượng người truy cập tăng đột biến, vượt quá khả năng xử lý của hệ thống.
• Cơ sở dữ liệu cho các hoạt động kinh doanh thiết yếu bị lỗi.
• Virus, worm lây nhiễm trên nhiều máy chủ.
• Thông tin cá nhân nhạy cảm của một số lượng lớn cá nhân vô tình bị lộ ra bên ngoài.

Lưu ý, tất cả các Thảm Họa (disasters) đều là Sự Cố Nghiêm Trọng, và một sự cố nhỏ nếu không được xử lý kịp thời cũng có thể trở thành Sự Cố Nghiêm Trọng.

Sự Cố Nghiêm Trọng _ các đặc điểm chính

Một số đặc điểm của một Sự Cố Nghiêm Trọng bao gồm :

• Khả năng một số lượng lớn khách hàng và/hoặc khách hàng quan trọng sử dụng dịch vụ đang hoặc sẽ bị ảnh hưởng.
• Chi phí/mất mát đối với khách hàng và/hoặc nhà cung cấp dịch vụ đang hoặc sẽ tăng cao, tính chung cho cả chi phí gián tiếp và chi phí trực tiếp.
• Danh tiếng của nhà cung cấp dịch vụ bị ảnh hưởng nghiêm trọng.

VÀ

• Thời gian và lượng tài nguyên cần thiết để quản lý và xử lý sự cố là rất lớn, cũng như nhiều khả năng việc không đáp ứng được SLA như đã thỏa thuận sẽ xảy ra.

Một Sự Cố Nghiệm Trọng luôn có mức độ ưu tiên là Khẩn Cấp hoặc Cao.

 

 

 

 

Read More

Hyperthread Core Sharing & CPU Affinity

Với CPU của một máy ảo, bên cạnh những cấu hình liên quan đến việc chia sẻ tài nguyên (Shares, Reservation, Limit), ESXi còn cho phép chỉnh sửa 02 tính năng nâng cao khác : đó là Hyperthreaded Core Sharing và CPU Affinity.

Hyperthreaded Core Sharing (HCS)

ESXi cung cấp 03 mode hoạt động Hyperthreaded Core Sharing như bên dưới :

Các lựa chọn Hyperthreded Sharing này hoàn toàn không ảnh hưởng đến độ ưu tiên sử dụng physical CPU của các máy ảo. Các thông số Shares, Reservation, Limit vẫn giữ vai trò quyết định đến độ ưu tiên và quá trình phân phối tài nguyên của hệ thống.

Với những workload bình thường, chúng ta nên giữ nguyên mode Any mặc định. Trong một số trường hợp đặc biệt, ví dụ với những ứng dụng thường xuyên làm cho bộ nhớ cache của CPU bị thrash thì nên cài đặt mode None cho máy ảo chạy ứng dụng đó.

Ngoài ra, cũng cần lưu ý là khi một vCPU nào đó ở mode None nhưng thời điểm này lại có một vCPU khác đang được cấp phát tài nguyên (nhắc lại là việc vCPU nào được cấp phát tài nguyên phụ thuộc vào các tham số Shares, Reservation và Limit) thì vCPU ở mode None sẽ bị descheduled khỏi cores đó. (vCPU ở mode None không chia sẻ core với các vCPU khác). Tình huống này trở nên đặc biệt xấu khi số lượng cores của hệ thống không nhiều và vCPU ở mode None không thể tìm được core nào để schedule các instruction của nó, từ đó performance của VM tương ứng sẽ bị downgrade nghiêm trọng.

CPU Affinity

VM-VM Affinity cho phép 02 VMs luôn nằm chung 01 host.
Host-VM Affinity cho phép 01 VM nào đó luôn nằm ở 01 host nào đó.
--> tương tự như vậy, CPU Affinity cho phép các vCPU của 01 VM sẽ nằm trên 1 tập hợp processors nào đó. Trong trường hợp sử dụng hyperthreading, processors nói ở trên là các logical processors / threads.
Trong trường hợp không sử dụng hyperthreading, processors là các cores nằm trên các sockets.

Khi cấu hình CPU Affinity cho 1 VM thì cấu hình này sẽ được áp dụng cho tất cả vCPU cùng các threads khác thuộc về VM đó. Các threads khác ở đây là những threads xử lý các tiến trình liên quan đến việc emulate mouse, keyboard, screen, CD-ROM và 1 số thiết bị thông dụng khác.

Trong một số trường hợp, ví dụ như khi VM cần sử dụng cả vCPU và các thread cùng lúc thì việc sử dụng CPU Affinity có thể downgrade performance của hệ thống khi mà processor chỉ có thể scheduled cho hoặc là CPU hoặc là thread tại 1 thời điểm cụ thể. Ví dụ cụ thể của tình huống này là khi VM chỉ có 1 vCPU được affnity đến 1 processor hoặc khi VM có 2 vCPU được affinity đến 2 processors.

Để tránh trường hợp trên xảy ra, ta nên bổ sung thêm tối thiểu 01 physical processors vào danh sách các processors được affinity. Ví dụ như VM có 1 vCPU được affinity đến 02 processors hay VM có 2 vCPU được affinity đến 03 processsors.

Một số lưu ý khi sử dụng CPU Affinity

1. Với hệ thống multiprocessors, ESXi tự động load-balancing giữa các socket, core, thread. Việc sử dụng CPU Affinity sẽ phát vỡ hoạt động load-balancing này.
2. Cấu hình Affinity có thể không đồng bộ với cấu hình Reservation và Shares giữa các VM
3. CPU Admission Control (chỉ bật VM khi có đủ Reservation Resources) không xem xét các cấu hình CPU Affinity do đó sẽ có trường hợp VM không có đủ tài nguyên như giá trị Reservation được cấu hình. Ví dụ : 
• VM1 có CPU Reservation là 1GHZ. 
• Host có 02 cores (không kích hoạt Hyperthread) : core 1 còn 500GHz available, core 2 còn 700GHz available. 
• VM1 được cấu hình CPU Affinity với core 1. 
• --> host nhận thấy số lượng CPU Available là 500GHz + 700GHz =1,2GHz > 1GHz do đó VM1 vẫn được power on, nhưng vì VM1 chỉ được phép hoạt động trên CPU core 1 nên VM1 chỉ sử dụng được tối đa 500GHz còn available của core 1.
4. CPU Affinity không tương thích với vMotion và các ứng dụng hoạt động dựa trên vMotion.
5. CPU Affinity ảnh hưởng đến hiệu quả sử dụng tài nguyên chia sẻ trên hệ thống multiprocessor.

Read More

VMware Resource Allocation

Resource theo tiếng Việt nghĩa là "tài nguyên" mà tài nguyên thì ai cũng muốn giành lấy cho mình, chính vì vậy việc quản lý tài nguyên đã, đang và sẽ trở thành vấn đề thiết yếu đối với bất kỳ hoạt động nào. Trừ những trường hợp tài nguyên được độc quyền khai thác vô tội vạ bởi một số tổ chức, còn lại thì tài nguyên cần được quản lý và phân phối hợp lý cho các đối tượng cần sử dụng nó, đơn giản chỉ vì cung luôn ít hơn cầu.

Việc quản lý hệ thống VMware cũng không nằm ngoài xu hướng đó với 4 loại tài nguyên quan trọng : CPU, Memory, Storage và Network.

• Chủ sở hữu 04 loại tài nguyên trên là ai ? _ Là các host hay cluster, datacenter được dựng nên từ các hosts.
• Cái gì sẽ sử dụng những tài nguyên đó ? _ Là các máy ảo và các resource pools.
• Đơn vị để định lượng tài nguyên là gì ?
• CPU : MHz
• RAM : MB
• Storage : IOPS
• Có những cơ chế phân phát tài nguyên nào ?
• Limit : Là lượng tài nguyên lớn nhất mà 1 máy ảo hay 1 resource pool có thể sử dụng. Chủ sở hữu không bao giờ cấp phát lượng tài nguyên vượt quá giá trị limit này dù rằng chủ sở hữu còn nhiều tài nguyên để không !
• Reservation : Là lượng tài nguyên mà chủ sở hữu đảm bảo sẽ cung cấp cho 1 máy ảo hay 1 resource pool. Nếu một máy ảo được chủ sở hữu hứa sẽ cung cấp A tài nguyên, nhưng hiện tại chủ sở hữu chỉ còn A1 tài nguyên trong đó A1 < A thì máy ảo đó sẽ không thể khởi động được.
• Shares : Thể hiện mối tương quan về độ ưu tiên của các máy ảo/resouce pool. Hãy tưởng tượng 1 công ty phát hành ra thị trường 10,000 cổ phiếu : bạn nắm trong tay 2,000 cổ phiếu tương đương 20% và vợ bạn nắm 3,000 cổ phiếu tương đương 30% (5,000 cổ phiếu còn lại thuộc về những cổ đông khác), khi đó độ ưu tiên sử dụng tài nguyên của bạn chỉ bằng 2/3 vợ bạn. Bên cạnh đó, nếu công ty phát hành thêm 5,000 cổ phiếu nữa để nâng tổng mức cổ phiếu phát hành lên 15,000 cổ phiếu thì lúc này tỷ lệ sở hữu của bạn giảm từ 20% xuống còn 13,33% (=2,000 / 15,000 * 100%) và của vợ bản giảm từ 30% xuống còn 20% (=3,000 / 15,000 * 100%)

Phần tiếp theo, chúng ta cùng đi sâu hơn vào các cơ chế phân phối tài nguyên này.

Share

Có 4 lựa chọn với cơ chế Share :  Low, Normal, High và Custom

Tỷ lệ tương quan Low : Normal : High là 1 : 2 : 4, cụ thể như sau :

như vậy, với thông tin bên dưới

tất cả các máy ảo DC, VMware vCener Server App..., OpenFiler và anhvt đều được cấu hình Shares ở mức Normal, tuy nhiên do 03 máy ảo DC, VMware vCenter Server App... và OpenFiler đều có 02 vCPU nên Share Value sẽ là 1000*2 = 2000 còn anhvt chỉ có Share Value 1000 do chỉ có 01 vCPU.

Tổng Shares đang có là 1000+2000+2000+2000 = 7000, do đó % Shares của anhvt là 1000/7000 ~ 14% và % Shares của các máy ảo còn lại bằng nhau và bằng 2000/7000 ~ 28%.

Nếu số lượng cổ phiếu phát hành tăng thêm 1000 đơn vị, hay số lượng Shares tăng lên thành 8000 (thêm 1 máy ảo nữa có Shares Value là 1000 _ trong trường hợp này là máy ảo có tên Backup DC) như trường hợp dưới đây

thì tương quan %Shares giữa các máy ảo sẽ thay đổi. 

Lúc này, % Shares của anhvt chỉ còn 12% (1000/8000) còn 3 máy ảo ban đầu cũng chỉ còn 25% (2000/8000).

Lấy một ví dụ khác : Ngân sách hàng năm của cả nước là 500,000 tỷ. Hà Nội được cấp 5%, Hồ Chí Minh 5%, Đà Nẵng 4%, Hải Phòng 2% ... Trong nội bộ Hà Nội, sở giao thông được cấp 20%, sở giáo dục 19%, sở y tế 10%... Giả sử có sự thay đổi về việc phân bổ ngân sách trong nội bộ thành phố Hà Nội khi sở giao thông được tăng ngân sách lên 25% thì sự thay đổi này, như chúng ta có thể dễ dàng nhận thấy, chỉ ảnh hưởng đến mức ngân sách của các sở ban ngành của riêng thành phố Hà Nội mà thôi. Còn ngân sách của các thành phố khác thì hoàn toàn không bị ảnh hưởng !

Điều này cũng đúng với việc phân bổ Shares mà chúng ta đang xét. Sự thay đổi về Share Value hay % Share  chỉ tác động đến các đối tượng ngang cấp, cụ thể là các máy ảo hoặc Resource Pool có chung parent pool, còn các máy ảo và Resource Pool khác hoàn toàn không bị tác động.

Điểm thứ ba cần nói về cơ chế phân phối Shares là sự ảnh hưởng của việc tắt/bật máy ảo đến tài nguyên thực sự được phân phối cho các máy.

Ví dụ Resource Pool A với tổng CPU là 12GHz có 03 máy ảo : VM1, VM2, VM3 với tỷ lệ %Shares CPU tương ứng là 30%, 30%, 40%.

Nếu VM1 và VM2 bật còn VM3 tắt thì VM1 có thể sử dụng 6GHz CPU và VM2 có thể sử dụng 6GHz CPU (vì tương quan tỷ lệ giữa VM1 và VM2 là 50:50)

Nếu VM3 bật lên thì khi đó VM1 và VM2 chỉ có thể sử dụng 3,6GHz CPU (=12GHz * 30%) cho mỗi máy ảo

Reservation

Reservation cho phép ESXi hosts có thể đảm bảo một lượng tài nguyên tối thiểu cho máy ảo hoặc cho resource pool khi cần thiết. Reservation chỉ thực sự có ý nghĩa khi resource contention xảy ra, còn trong trường hợp các resources vẫn available thì các máy ảo hoặc resource pool có thể sử dụng lượng tài nguyên lớn hơn giá trị reservation này.

Khi một máy ảo được đảm bảo một lượng resource tối thiểu thông qua reservation nhưng hiện tại hosts không còn đủ tài nguyên thì máy ảo đó sẽ không thể power on được.

Yếu tố "đảm bảo lượng tài nguyên tối thiểu KHI CẦN THIẾT" cũng cần được lưu ý. Lấy ví dụ, ESXi host còn 2GHz available và reserve 1GHz cho VM1 và 1GHz cho VM2. Nếu VM1 chỉ sử dụng 500MHz thì VM2 hoàn toàn có thể sử dụng 1,5GHz tài nguyên. Trong trường hợp VM1 muốn sử dụng 1GHz thì VM2 sẽ buộc phải release 0,5GHz đang dùng để trả lại cho VM1.

Mặc định, giá trị reservation bằng 0 và chúng ta có thể sử dụng reservation đối với các tài nguyên RAM và CPU.

Limit
Ngược lại với Reservation khi ESXi host đảm bảo một lượng tài nguyên tối thiểu cho máy ảo hoặc resource pool, giá trị Limit lại là chặn trên cho các tài nguyên này. Điều này có nghĩa, nếu máy ảo được gán một giá trị limit là X thì trong mọi trường hợp, máy ảo đó không thể sử dụng tài nguyên vượt quá giá trị X này. Ngay cả trong trường hợp cấu hình ban đầu của máy ảo có dung lượng RAM là 2GB nhưng nếu giá trị limit gán cho máy ảo là 1,5GB thì máy ảo cũng chỉ có thể sử dụng tối đa 1,5GB mà thôi.

Limit đặc biệt có ý nghĩa trong trường hợp sau : ESXi host của bạn có 16GB RAM và hiện mới chỉ có 2VM, mỗi VM được cấu hình sử dụng 7GB RAM dù thực tế các ứng dụng trên VM chỉ cần 2GB RAM là có thể hoạt động tốt. 5 máy ảo nữa được tạo thêm trên ESXi host và người quản trị muốn 02 VM ban đầu chỉ sử dụng 2GB RAM đúng nhu nhu cầu của chúng. Thông thường, nếu không có tính năng Limit, người quản trị phải tắt máy ảo, chỉnh lại thông số RAM xuống 2GB rồi bật lại máy ảo. Thực tế không phải lúc nào cũng dễ dàng như vậy đặc biệt với các máy ảo chứa các ứng dụng quan trọng cần độ sẵn sàng cao. Trong trường hợp này, Limit sẽ giúp người quản trị giới hạn dung lượng RAM sử dụng của 02 VM ban đầu mà không cần phải tắt/bật máy ảo. Quả thật là tiện lợi !!!

Limit có thể được sử dụng đối với các tài nguyên RAM, CPU và Storage I/O.
Mặc định, ESXi host cho phép các máy ảo hay resource pool sử dụng tối đa (unlimited) lượng tài nguyên được cấu hình ban đầu và trong đa số trường hợp, chúng ta không cần thiết phải sử dụng thông số Limit này. Dưới đây là một số điều lưu ý khi sử dụng Limit :

• Lợi thế : Ngay từ đầu, hạn chế kỳ vọng của người sử dụng. Nếu người dùng đầu cuối chỉ cần dùng 2GB RAM nhưng chúng ta lại cho họ 7GB RAM thì về sau khi áp lại 2GB RAM (5GB RAM kia chia sẻ cho các người dùng/máy ảo khác) người dùng chắc chắn sẽ phàn nàn (dù rằng họ vẫn có đủ tài nguyên cho các công việc của mình)
• Bất lợi : Sử dụng Limit, chúng ta có thể lãng phí tài nguyên khi còn nhiều tài nguyên không được sử dụng cho các máy ảo hay resource pool. Chỉ cấu hình limit khi bạn có lý do thật xác đáng để làm điều đó.

Một số lưu ý khi thực hiện quá trình phân phối tài nguyên

Tùy thuộc vào điều kiện môi trường ESXi mà các máy ảo đang hoạt động, việc lựa chọn sử dụng Shares, Reservation hay Limit cần được xem xét cẩn thận để mang lại hiệu quả tối ưu.

1. Nếu hệ thống có lượng tài nguyên (CPU, RAM, Storage) thường xuyên thay đổi (nâng cấp, bổ sung ...), sử dụng Shares sẽ mang lại hiệu quả cao nhất trong việc phân phối tài nguyên ở mức hợp lý cho các máy ảo hoặc resource pool. Trước khi nâng cấp hệ thống, tỉ lệ tài nguyên của VM1 và VM2 là 1:2 thì sau khi nâng cấp, tỉ lệ này vẫn được giữ nguyên (tuy mức giá trị tuyệt đối có tăng/giảm)
2. Sử dụng Reservation cho lượng tài nguyên (CPU, Memory) tối thiểu mà máy ảo/resource pool có thể chấp nhận được, chứ Reservation không phải lượng tài nguyên bạn mong muốn máy ảo/resource pool sở hữu (đương nhiên số lượng bạn mong muốn phải lớn hơn nhiều số lượng tối thiểu bạn có thể chấp nhận được). Khi hệ thống được nâng cấp/hạ cấp thì giá trị Reservation này không thay đổi.
3. Cố gắng tránh Reserve 100% tài nguyên được cấu hình của máy ảo hoặc resource pool, nên để lại tối thiểu 10% tài nguyên để tránh trường hợp các máy ảo không thể power on hoặc DRS không thể migrate máy ảo giữa các hosts.

Read More

New Networking Features : Configuration Backups and Rollbacks

Chuỗi bài viết về các tính năng Networking mới trong vSphere 5.1 sẽ tiếp tục với 02 tính năng : Configuration Backup and Restore và Rollback and Recovery.

Configuration Backup and Restore

Trước phiên bản vDS 5.1, việc thay đổi một cấu hình vDS đang hoạt động tốt gây ra nhiều ngại ngần cho người quản trị. Thông thường, bạn sẽ phải kiểm tra rất kỹ những thay đổi đó sẽ ảnh hưởng thế nào đến vDS, và phải thực sự chắc chắn bạn sẽ không mất kết nối đến vDS hay vCenter Server sau khi apply các thay đổi đó. Bên cạnh đấy, cũng không có một phương pháp đơn giản và dễ dàng nào để backup cấu hình của vDS đề phòng trường hợp bạn muốn restore lại những cấu hình đó.

Với những tính năng mới trong vDS 5.1, bây giờ bạn đã có thể :

1. Backup cấu hình vDS hoặc portgroup ra ổ đĩa với chức năng Export
2. Restore cấu hình vDS hoặc portgroup với chức năng Restore
3. Thêm các đối tượng mới vào file backup với chức năng Import
4. Revert lại câu hình portgroup cũ

Một số ảnh capture về những chức năng mới bạn có thể thực hiện với vDS

Cùng xem xét ví dụ sau 

Backup vDS

Click chuột phải vào vDS switch --> chọn "Export Configuration...", điền các thông tin description cần thiết

Có hai lựa chọn backup cho bạn : Backup cấu hình của vDS + port groups hoặc chỉ backup cấu hình của vDS. (lưu ý là chúng ta không có lựa chọn : Chỉ backup cấu hình của port groups). Sau khi quá trình backup hoàn tất, hệ thống sẽ yêu cầu bạn save lại file backup.

Thay đổi cấu hình vDS

Bây giờ tôi sẽ remove portgroup có tên VLAN254

Sau khi portgroup VLAN254 bị remove, hệ thống sẽ thông báo cho tôi về kết quả này.

Restore Configuration

Portgroup VLAN254 quay trở lại hệ thống sau khi tôi thực hiện quá trình Restore

Quá trình này thực sự quá đơn giản để có thể diễn tả chi tiết hơn !!!

Với tính năng Backup and Restore này, bạn có thể tạo ra vDS chuẩn sau đó deploy các vDS trên toàn hệ thống. Hoặc bạn có thể xây dựng vDS trong môi trường lab để kiểm tra mọi tính năng của nó, sau đó mới triển khai trên môi trường thực tế.

---------------------------------------------------------------------------------------------------------

Rollback and Recovery

Một trong những điểm mạnh của distributed switch là những thay đổi trên nó sẽ được apply trên tất cả các hosts kết nối đến switch. Nhưng điểm mạnh này cũng đồng thời là gót chân asin của distributed switch trong trường hợp có lỗi cấu hình đối với phân vùng mạng quản lý, từ đó có thể dẫn đến những hậu quả như các hosts mất kết nối tới vCenter Server ... Tính năng Rollback giải quyết vấn đề này bằng cách cố gắng "hiểu" các sự thay đổi cấu hình trước khi apply nó, đồng thời roll back lại trạng thái cấu hình cũ nếu cấu hình mới gây ra sự mất kết nối đến hệ thống.

Cùng xem xét hình vẽ dưới đây (được cung cấp bởi VMware). Tôi đã vẽ thêm 02 mũi tên trỏ vào nơi VMKernel port kết nối với distributed switch. Khi một sự thay đổi dẫn đến sự mất kết nối từ host đến vCenter, Rollback sẽ ngăn chăn hành động đó và không apply những thay đổi này.

Đương nhiên, tính năng Rollback có thể bị disabled nếu bạn muốn

Bên cạnh đó, nếu Rollback không ngăn chặn được những thay đổi gây nên sự mất kết nối của hosts đến vCenter Server thì giao diện DCUI bổ sung thêm 1 lựa chọn mới để Recover lại những cấu hình cũ. Tính năng "Restore vDS" mới sửa lại những cấu hình trên vDS mà hệ thống vừa apply.

Khi đã ở trong màn hình Restore vDS, bạn có thể sửa những lỗi cấu hình như - port bị blocked, các chính sách teaming, VLAN như hình dưới đây

Kết luận : Configuration Backup, Rollbacks và Recovery là những công cụ mới mang lại sự thuận tiện cho cán bộ quản trị hệ thống vSphere khi phải làm việc với vDS. Theo quan điểm cá nhân, VMware đã mang lại một sự cải tiến tốt thông qua việc thực sự lắng nghe những phản hồi khách hàng cũng như thông qua những nỗ lực miệt mài của đội ngũ kỹ sư chuyên nghiệp của mình.

Read More

New Networking Features : Network Health Check

vSphere 5.1 giới thiệu nhiều tính năng Networking mới cho vDS (virtual Distributed Switch), qua đó nâng cao hiệu năng sử dụng hệ thống vSphere và mang lại sự đơn giản, thuận tiện cho người sử dụng.

Bài viết này sẽ tập trung giới thiệu về Network Health Check (NHC)_ một trong 7 tính năng mới mà vSphere 5.1 mang lại cho người dùng.

Network Health Check (NHC) cho phép người quản trị kiểm tra được liệu hệ thống mạng có bị cấu hình lỗi gây ra sự không tương thích giữa virtual switch và physical switch hay không.

NHN thực hiện quá trình kiểm tra đối với 3 thông số : VLAN, MTU, và NIC Teaming.

Chúng ta cùng lấy ví dụ với hệ thống mạng như topology dưới đây :

VLAN Mismatch

VLAN Mismatch xảy ra khi cấu hình về VLAN trên virtual switch và trên physical switch không tương thích với nhau, và điều này thì quá thường xuyên xảy ra, đặc biệt trong trường hợp người quản trị mạng và người quản trị hệ thống ảo hóa không có được sự tương tác/giao tiếp tốt. Ví dụ như, bạn sử dụng VLAN 100 cho các máy ảo thuộc port group A, tuy nhiên VLAN 100 lại chưa được cấu hình trên physical switch. Bạn chỉ có thể phát hiện ra sự không tương thích này khi bật máy ảo đó lên và thử kiểm tra kết nối đến hệ thống mạng bên ngoài (ping, tracert ...).

Trong ví dụ cụ thể dưới đây, tôi kích hoạt tính năng Health Check và tạo ra 3 port groups với 3 VLANs tương ứng là 10, 254 và 555.

 Với cấu hình này, VLAN 10 là VLAN duy nhất có traffic được physical switch "tiếp nhận" và có được "Supported" status còn các VLAN còn lại đều có trạng thái "Not supported"

Với thông tin này, tôi biết được mình cần phải xem lại cấu hình VLAN trên physical switch hoặc sử dụng 1 VLAN khác trên virtual switch. Trong ví dụ trên, tôi hoàn toàn chưa sử dụng bất kỳ một máy ảo nào, qua đó có thể thấy chức năng Health Check có thể hoạt động hoàn toàn độc lập với các máy ảo.

Về mặt hoạt động chi tiết, vDS chỉ gửi một vài gói tin broadcast để kiểm tra sự tồn tại của các VLAN trong mạng. Điều này sẽ giới hạn việc kiểm tra chỉ ở các access switch chứ không tác động lên các distribution hay core switch.

MTU Mismatch

Network Health Check cũng có thể kiểm tra sự không đồng bộ về MTU giữa vNIC, virtual switch, physical adapter (vmnic) và port trên physical switch. Điều này mang lại sự thuận tiện cho người quản trị trong trường hợp họ cần sử dụng tính năng Jumbo Frame trên các gói tin (có quá nhiều điểm/thiết bị cần phải thay đổi cấu hình MTU).

Teaming Mismatch

Đối tượng có thể kiểm tra cuối cùng của Network Health Check là sự không đồng bộ về mặt Network Teaming. Nếu physical switch được cấu hình EtherChannel, thì teaming policy trên port group cũng phải là IP Hash.

Trong ví dụ bên dưới, tôi kích hoạt policy IP Hash trên portgroup nhưng trên physical switch tôi không cấu hình EtherChannel. Điều đó tạo ra sự không đồng bộ giữa virtual switch và physical switch và nhận được thông báo như bên dưới :

Read More

vSphere 5.1 : New features for Networking

Bài viết tổng hợp một số thay đổi/bổ sung/cải tiến đối với networking features trong vSphere 5.1

vDS (virtual Distributed Switch) là một virtual switch cung cấp tính năng quản lý tập trung và có thể span trên nhiều host (ngược với Standard Switch chỉ có thể cung cấp tính năng networking cho duy nhất 01 host), từ đó mang đến nhiều tính năng nâng cao liên quan đến networking trong hệ thống vSphere.

Tuy nhiên, người dùng cũng gặp một số trở ngại trong quá trình thao tác với vDS như việc phải recover lại cấu hình networking cho các host trong một số tình huống lỗi phát sinh. Những tình huống này có thể bao gồm : lỗi cấu hình đối trên hệ thống management network dẫn tới việc mất kết nối đến vCenter Server; hay như quá trình khôi phục sau thảm họa với toàn hệ thống data center... vSphere 5.1 giải quyết được những vấn đề này đồng thời mang đến nhiều công cụ/đặc tính mới để nâng cao hiệu quả của hoạt động networking.

1. Nework health check
2. VDS configuration backup and restore
3. Management network rollback and recovery
4. Distributed port - auto expand
5. MAC address management
6. Link Aggregation Control Protocol (LACP) support
7. Bridge Protocol Data unit filter

Network Health Check

Cấu hình networking trong vSphere bao gồm 2 bước : cấu hình switch vật lý và cấu hình vDS. Các tham số quan trọng như VLAN, network adapter teaming và MTU cần được cấu hình chính xác trên cả switch vật lý và switch ảo; nếu không sẽ có nhiều lỗi kết nối có thể xảy ra trong quá trình vận hành hệ thống vSphere. Thông thường những lỗi kết nối có nguyên nhân từ việc cấu hình không chính xác không dễ để phát hiện, đặc biệt trong môi trường vân hành mà người quản trị mạng và người quản trị hệ thống ảo hóa là khác nhau và không có sự tương tác hiệu quả. Trong các version vSphere trước, VMware không đưa ra bất cứ công cụ nào để phát hiện và khắc phục quá trình cấu hình sai trên hệ thống switch thật và switch ảo.

Tính năng Network Health Check trong vSphere 5.1 theo dõi và giám sát định kỳ các tham số sau :

1. VLAN
2. MTU
3. Network adapter teaming

Mặc định, chu kỳ theo dõi/kiểm tra của vDS là 1 phút. Trong khoảng thời gian này, những gói tin dò tìm lớp 2 (layer 2 Ethernet probing) được gửi đi và nhận về thông qua uplink interface của vDS. Những gói tin REQ (request) và ACK (acknowledge) được tiếp nhận hoặc loại bỏ (received or dropped) tùy thuộc vào cấu hình của thiết bị mạng vật lý mà uplink interface kết nối đến. Gói tin bị loại bỏ (dropped) là dấu hiệu của việc đã có lỗi phát sinh trong quá trình cấu hình thiết bị (switch vật lý và switch ảo không được cấu hình tương thích), và một thông báo cảnh báo sẽ xuất hiện trên cửa sổ VMware vSphere Client.

Để Network Health Check có thể hoạt động, những yêu cầu sau cần được đáp ứng:

1. VLAN và MTU : Có ít nhất 2 physical uplinks kết nối đến vDS
2. Teaming policy : Có ít nhất 2 active uplinks trong team và có ít nhất 2 host trong vDS

vDS Configuration Backup and Restore

Việc cấu hình vDS được thực hiện thông qua vCenter Server, bên cạnh đó mọi tham số cấu hình đều được lưu trong cơ sở dữ liệu của vCenter Server do đó nếu cơ sở dữ liệu này gặp lỗi hoặc hệ thống mất kết nối đến vCenter Server thì người dùng sẽ không thể khôi phục lại những cấu hình network của họ và bắt buộc phải reset lại cấu hình mạng từ đầu. Bên cạnh đó, cũng không có một cách thức đơn giản nào để replicate cấu hình mạng hay có thể revert ngược đến các trạng thái hoạt động trước sau khi sự cố đã xảy ra.

vDS Configuration Backup and Restore ra đời để khắc phục những nhược điểm trên. Người dùng có thể thực hiện take snapshot cấu hình mạng trên vDS cũng như trên port group, qua đó có thể dễ dàng kiểm soát những thay đổi đã xảy ra với cấu hình mạng trên vDS (revert ngược đến 1 trạng thái cấu hình mạng trong quá khứ ...) cũng như có thể tạo template để có thể tạo ra các cấu hình vDS tương tự trong trường hợp cần thiết.

vDS Configuration Backup and Restore hỗ trợ những tính năng cụ thể sau :

1. Sao lưu cấu hình vDS và port group. Người dùng có thể lựa chọn lưu dữ liệu trên local disk hoặc trên SAN thông qua VMware vSphere Web Client.
2. Khôi phục cấu hình vDS và port group từ các bản sao lưu.
3. Tạo mới vDS hoặc port group từ các bản sao lưu.
4. Roll back cấu hình về trạng thái trước. Tính năng này đặc biệt hữu hiệu khi người dùng thay đổi cấu hình networking nhưng kết quả không như mong đợi và người dùng muốn quay trở lại với những cấu hình trước.

Management Network Rollback and Recovery

Phân vùng mạng quản lý (management network) được cấu hình trên các host để giao tiếp với vCenter Server cũng như với các host khác trong quá trình thực hiện VMware vSphere High Availability. Phân vùng này đóng vai trò thiết yếu trong quá trình quản lý tập trung hệ thống vSphere thông qua vCenter Server. Nếu phân vùng mạng quản lý bị lỗi, vCenter Server sẽ mất kết nối đến các host, dẫn đến việc tính năng quản lý tập trung cũng không còn.

Đối với vSphere Standard Switch (vSS), qua giao diện console trực tiếp, người dùng có thể khôi phục lại hoạt động của switch ảo khi có lỗi xảy ra với phân vùng mạng quản lý bằng cách reset lại cấu hình mạng về cấu hình mặc định ban đầu.

Tuy nhiên, trong môi trường vDS _ khi mà tất cả host được kết nối đến vDS _ thì việc cấu hình sai vDS hoặc việc phát sinh sự cố với vDS cũng có thể khiến tất cả các host bị mất kết nối đến vCenter Server. Khi đó, vCenter Server sẽ không thể thay đổi cấu hình trên vDS và đẩy những cấu hình này xuống các host được nữa. Trong phiên bản vSphere 5.0, cách duy nhất để khôi phục lại hoạt động của toàn hệ thống là phải đến từng host, cấu hình lại vSS một cách thật chính xác, rồi sau đó mới tiến hành cấu hình vDS và kết nối các host vào vDS mới tạo ra này.

Để tránh sự phức tạp này, đối với những hệ thống có đủ số lượng physical NICs, người quản trị thường cấu hình phân vùng mạng quản lý trên vSS còn vDS để phục vụ cho tất cả các traffic còn lại. Trong trường hợp này, các hosts cần có tối thiểu 4 physical NICs : 2 cho vSS và 2 cho vDS.

Tính năng Automatic Rollback and Recovery trong vSphere 5.1 sẽ giải quyết tất cả những vướng mắc liên quan đến việc sử dụng phân vùng mạng quản lý trên vDS. Để thực hiện điều đó, Automatic Rollback and Recovery tự động phát hiện và lưu lại những thay đổi cấu hình trên phân vùng mạng quản lý. Khi host mất kết nối đến vCenter Server, nó sẽ tự động revert ngược đến trạng thái cấu hình hoạt động tốt trước đấy. Bên cạnh đó, người dùng có thêm tính năng cấu hình lại phân vùng mạng quản lý của vDS trên giao diện console trực tiếp (với các phiên bản vSphere trước, chúng ta chỉ có thể cấu hình lại phân vùng mạng quản lý cho vSS).

Distributed Port - Auto Expand

Distributed Port (DP) trong vDS là những port được sử dụng để kết nối đến VMkernel hoặc đến các máy ảo. Cấu hình của DP được thiết lập thông qua các tham số của Distributed Port Group (DPG). Với các tham số này, người dùng có thể lựa chọn số lượng DP ứng với mỗi DPG thông qua việc lựa chọn 1 trong 3 phương thức sau :

1. Static binding : vCenter Server tạo ngay số lượng DP được khai báo trong DPG. Khi một máy ảo kết nối đến DPS, một DP sẽ được gán cho máy ảo đó. Ngay cả khi máy ảo ở trạng thái tắt, DP ở trên vẫn thuộc về máy ảo đó.
2. Dynamic binding : Hoạt động hoàn toàn giống static binding ngoại trừ việc DP sẽ không còn thuộc về máy ảo khi máy ảo ở trạng thái tắt.
3. Ephemeral binding : Hoạt động của vDS trong việc tạo port sẽ giống với vSS nếu người dùng lựa chọn option này. Mặc định sẽ không có bất kỳ DP nào được tạo ra, hay nói cách khác số lượng DP được tạo ra ban đầu là 0. Khi có một máy ảo ở trạng thái bật (power-on) kết nối đến DPS, DP sẽ được tạo ra và gán cho máy ảo đó. Số lượng tối đa các máy ảo có thể kết nối đến 1 port group phụ thuộc vào số lượng port tối đa mà switch ảo có thể hỗ trợ. Theo tài liệu vSphere Configuration Maximum guide (https://www.vmware.com/pdf/vsphere5/r50/vsphere-50-configurationmaximums.pdf), một host có thể có tối đa 4096 ports và tối đa 1016 ports hoạt động đồng thời.

Lưu ý : Chỉ với lựa chọn static binding, người dùng mới có thể thực hiện stateful monitoring trên các distributed ports. 

Với tính năng Auto Expand, khi số lượng DP cấu hình trên DPS đã được sử dụng hết nhưng vẫn có máy ảo muốn kết nối đến DPS, hệ thống sẽ tự động bổ sung thêm DP vào DPS. Để tính năng này có thể hoạt động, người dùng cần thực hiện các câu lệnh vSphere API hay vSphere MOB được mô tả ở KB 1022312 (http://

kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1022312.)

Auto Expand đã được giới thiệu từ vSphere 5.0. Với phiên bản vSphere 5.1, khi người dùng lựa chọn option static binding, Auto Expand sẽ tự động được kích hoạt, qua đó người dùng sẽ không cần thực hiện các đoạn script để khởi chạy Auto Expand cũng như không cần lo lắng về việc các DP sẽ bị cạn kiệt.

MAC Address Management

Trong môi trường vSphere, địa chỉ MAC của các card mạng Ethernet của các máy ảo được quản lý và cấp phát bởi vCenter Server. Địa chỉ MAC của các máy ảo trong cùng một mạng (subnet) cần phải khác nhau. Quá trình quản lý địa chỉ MAC trong vSphere 5.0 gặp một số giới hạn sau :

1. Mỗi vCenter Server chỉ có 64K dung lượng để lưu trữ thông tin về các địa chỉ MAC mà nó quản lý. Dung lượng này là quá nhỏ trông môi trường đám mây hiện nay.
2. Sự trùng lặp địa chỉ MAC có thể xảy ra nếu có nhiều vCenter Server cùng hoạt động nhưng được quản lý bởi các nhóm IT khác nhau.

Được giới thiệu trong vSphere 5.1, MAC Address Management cho phép người dùng (người quản trị hệ thống ảo hóa) tự xác định địa chỉ / dải địa chỉ MAC cho các máy ảo mà không giới hạn trong khuôn khổ dải địa chỉ của VMware (dựa trên 24 bits đầu tiên _OUI_ trong 48 bits địa chỉ MAC). Tất nhiên, người dùng vẫn có thể lựa chọn sử dụng dải địa chỉ của VMware như trước đây.

Giới hạn về 64K dung lượng lưu trữ địa chỉ MAC cũng được gỡ bỏ, và mối lo về việc trùng lặp địa chỉ MAC cũng không còn khi người dùng có thể tự phân hoạch hệ thống địa chỉ MAC cho mình.

Link Aggregation Control Protocol Support

Link Aggregation Control Protocol (LACP) nhóm các kết nối mạng vật lý lại với nhau để tạo thành 1 kết nối mạng logical duy nhất, qua đó tăng băng thông truyền tải cũng như đảm bảo tính redundancy cho các kết nối. Các LACP nodes (các thiết bị sử dụng giao thức LACP) trao đổi cấu hình với nhau thông qua các gói tin LACP packet. Tính năng LACP chính thức được hỗ trợ từ phiên bản vSphere 5.1, qua đó mang lại các ưu điểm sau :

1. Plug and Play - Tự động cấu hình và trao đổi các thông tin cần thiết giữa host và switch vật lý
2. Dynamic - Tự động phát hiện lỗi kết nối và chuyển sang những kết nối đang hoạt động

Bridge Protocol Data Unit Filter

Bridge Protocol Data Unit (BPDU) được sử dụng trong giao thức Spanning Tree Protocol (STP) trong việc chống loop layer 2 của hệ thống mạng. Các switch ảo VMware (vSS và vDS) không hỗ trợ STP do đó nó không trao đổi gói tin BPDU với hệ thống switch vật lý thông qua uplink interface.

Trong môi trường vSphere, khi ESXi host kết nối trực tiếp đến switch vật lý thông qua uplink interface, người dùng nên bật tính năng PortFast và BPDU guard trên switch vật lý để các máy ảo có thể sử dụng mạng vật lý một cách nhanh chóng, đồng thời switch vật lý cũng không cần phải tốn tài nguyên để gửi các gói tin BPDU đến các ESXi host một cách vô ích (vì các switch ảo không gửi/nhận các gói tin này).

Tuy nhiên, dù switch ảo không gửi/nhận các gói tin BPDU, nhưng nếu các máy ảo gửi các gói tin BPDU thì switch ảo sẽ forward những gói tin này đến switch vật lý. Nếu port trên switch vật lý được cấu hình BPDU guard thì khi nhận được các gói tin BPDU, port đó sẽ rơi vào trạng thái err-disabled và sẽ dừng hoạt động.  vSphere sẽ phát hiện được trạng thái dừng hoạt động này và chuyển hướng traffic của các máy ảo sang một uplink interface khác. Và một lần nữa, port mới này trên switch vật lý nếu nhận được gói tin BPDU thì cũng sẽ rơi vào trạng thái dừng hoạt động nếu tính năng BPDU guard được kích hoạt. Hiệu ứng domino này gây ra hiên tượng tất cả các port trên switch vật lý mà host có uplink kết nối đến đều bị dừng hoạt động và không cung cấp được kết nối ra mạng vật lý cho các máy ảo.

Tính năng BPDU Filter sẽ lọc các gói tin BPDU được gửi đi từ máy ảo, từ đó ngăn chặn việc switch vật lý sẽ nhận được các gói tin BPDU vào những port mà tính năng BPDU guard được kích hoạt. Tính năng này có trên cả vSS và vDS và có thể được kích hoạt thông qua việc thay đổi giá trị của tham số "net" trong cấu hình ESXi host.

Read More