Zoning trong SAN Switch “Trái tim” của bảo mật và quản trị SAN

Zoning là một trong những cơ chế quan trọng nhất trong Fibre Channel SAN. Nếu SAN Fabric quyết định các thiết bị nào có thể tồn tại và giao tiếp trong Fabric, thì Zoning quyết định thiết bị nào được phép nhìn thấy và giao tiếp với thiết bị nào.

Một thiết kế SAN tốt không đơn thuần là “Server nhìn thấy Storage”, mà phải đảm bảo:

  • Isolation giữa các hệ thống.
  • Chỉ cho phép các initiator truy cập đúng storage target cần thiết.
  • Giảm số lượng thiết bị mà HBA phải xử lý trong Fabric.
  • Hạn chế tác động khi một thiết bị hoặc cấu hình gặp sự cố.
  • Đảm bảo HA/Multipathing cho VMware, Database và các hệ thống quan trọng.
  • Dễ dàng mở rộng, thay đổi và troubleshooting.

1. Zoning là gì và tại sao cần Zoning?

1.1. Zoning là gì?

Zoning là cơ chế phân vùng logic trên SAN Fabric, được cấu hình trên SAN Switch nhằm xác định những Fibre Channel device nào được phép giao tiếp với nhau.

Có thể hình dung:

Nếu Server và Storage không nằm trong cùng Zone, chúng có thể cùng tồn tại trong Fabric nhưng không được phép giao tiếp trực tiếp với nhau.

1.2. Tại sao phải Zoning?

Nếu không zoning hoặc zoning quá rộng, một HBA có thể nhìn thấy rất nhiều thiết bị:

Điều này tạo ra một số vấn đề:

Security

Server A không nhất thiết phải nhìn thấy Storage của Server B.

Scalability

Fabric càng lớn thì số lượng device càng nhiều, việc kiểm soát và quản trị càng phức tạp.

Stability

Một thay đổi hoặc lỗi trên một vùng có thể tạo ảnh hưởng không cần thiết tới các hệ thống khác.

Troubleshooting

Khi Server nhìn thấy hàng chục hoặc hàng trăm target, việc xác định đúng đường đi I/O trở nên khó khăn.

Vì vậy:

Zoning nên được thiết kế theo nguyên tắc “chỉ cho phép những kết nối thực sự cần thiết”.

2. WWPN Zoning vs Port Zoning

Đây là một trong những quyết định quan trọng khi thiết kế SAN.

2.1. WWPN-based Zoning

WWPN – World Wide Port Name – là địa chỉ định danh duy nhất của FC Port, thường được gán cho HBA hoặc Storage Target Port.

Ví dụ:

Server HBA:
10:00:00:90:fa:12:34:56
Storage Target:
50:00:09:73:12:ab:cd:01

 

Zoning dựa trên WWPN:

Zone_VMware01
├── VMware_HBA01_WWPN
└── Storage_Target01_WWPN

 

Ưu điểm

  • Không phụ thuộc vào physical switch port.
  • Khi thay đổi cable hoặc chuyển HBA sang port khác, zoning vẫn có thể giữ nguyên.
  • Phù hợp với môi trường ảo hóa và hạ tầng lớn.
  • Dễ quản lý khi sử dụng NPIV.

Nhược điểm

  • Cần quản lý chính xác WWPN.
  • Nếu nhập nhầm WWPN, troubleshooting sẽ khó.
  • Cần xây dựng quy trình quản lý naming/alias tốt.

Khuyến nghị

WWPN zoning thường là lựa chọn ưu tiên cho môi trường SAN enterprise.

3. Port Zoning là gì?

Port zoning sử dụng physical switch port để xác định thành viên của Zone.

Ví dụ:

SAN Switch
Port 01 ─── Server HBA
Port 20 ─── Storage Target
Zone:
Port 01 ↔ Port 20

Ưu điểm

  • Dễ hiểu.
  • Dễ triển khai trong một số môi trường nhỏ.
  • Phù hợp với các hệ thống có topology cố định.

Nhược điểm

Giả sử Server đang ở:

Switch Port 01
sau đó chuyển sang:
Switch Port 10
thì zoning có thể không còn đúng.

Điều này làm tăng chi phí vận hành.

Khuyến nghị thực tế

Đối với môi trường Enterprise:

Ưu tiên WWPN-based zoning; hạn chế phụ thuộc vào physical Port zoning nếu không có yêu cầu đặc biệt.

4. Single Initiator – Single Target

Đây là một trong những nguyên tắc zoning quan trọng nhất.

Initiator

Thông thường là:

  • Server HBA
  • VMware ESXi HBA
  • Physical Database Server HBA
  • Backup Server HBA

Target

Thông thường là:

  • Storage Array FC Port
  • Storage Controller FC Port

Mô hình khuyến nghị:

Thay vì:
Single Initiator – Single Target

Mỗi Zone chỉ bao gồm:

1 Initiator
+
1 Target
Ví dụ:
Zone_ESXi01_HBA01_Target01
ESXi01_HBA01
Storage01_Target01
Sau đó tạo Zone khác:
Zone_ESXi01_HBA01_Target02
ESXi01_HBA01
Storage01_Target02

Tại sao không đưa nhiều Initiator vào một Zone?

Ví dụ không nên:

Zone_BAD
ESXi01_HBA01 ─┐
ESXi02_HBA01 ─┼──── Storage_Target01
ESXi03_HBA01 ─┘

Vì điều này làm tăng khả năng unintended visibility giữa các initiator và làm topology trở nên khó kiểm soát.


5. Best Practice về thiết kế Zoning

Một thiết kế SAN Enterprise nên tuân thủ một số nguyên tắc sau.

5.1. Single Initiator – Single Target

Đây là nguyên tắc quan trọng nhất:

1 HBA
└──── 1 Storage Target

Không nên tạo các Zone quá lớn.

5.2. Sử dụng Device Alias

Thay vì sử dụng WWPN khó đọc:

10:00:00:90:FA:12:34:56
nên đặt alias:
ESX01_HBA_A
Storage:
STG01_CTRL_A_P1
Sau đó:
zone_ESX01_A_STG01_A
Điều này giúp:
  • Dễ đọc configuration.
  • Dễ troubleshooting.
  • Giảm lỗi khi cấu hình.
  • Dễ bàn giao vận hành.

5.3. Tách Fabric A và Fabric B

Đối với hệ thống Enterprise, không nên thiết kế một Fabric duy nhất.

Mô hình khuyến nghị:

Fabric A và Fabric B nên độc lập, tránh single point of failure.

Không nên:

6. Zone, Zone Set và Fabric

Ba khái niệm này thường bị nhầm lẫn.

Zone

Zone là một nhóm các WWPN/FC device được phép giao tiếp với nhau.

Ví dụ:

Zone_ESX01_A_STG01_A
ESX01_HBA_A
STG01_CTRL_A

Zone Set

Zone Set là tập hợp nhiều Zone.

Ví dụ:

Production_ZoneSet
├── Zone_ESX01_A_STG01_A
├── Zone_ESX01_A_STG01_B
├── Zone_ESX02_A_STG01_A
├── Zone_ESX02_A_STG01_B
└── Zone_DB01_A_STG02_A

Chỉ Zone Set được activate mới trở thành cấu hình zoning đang có hiệu lực trên Fabric.

Có thể hình dung:

Zone Set
┌────────────┼────────────┐
▼ ▼ ▼
Zone 01 Zone 02 Zone 03
│ │ │
ESXi01 ESXi02 DB01
│ │ │
Storage Storage Storage

Fabric

Fabric là toàn bộ môi trường FC Switching tạo thành một SAN logical network.

Ví dụ:

SAN FABRIC
┌──────────────────┐
│ │
SAN Switch A ───── SAN Switch B
│ │
└─────── FC ───────┘

Trong môi trường Enterprise:

Fabric A ≠ Fabric B

và hai Fabric nên độc lập về:

  • Switch
  • ISL
  • HBA path
  • Storage path

7. Các lỗi Zoning phổ biến

Trong triển khai thực tế, lỗi zoning thường không nằm ở việc “không biết zoning”, mà nằm ở nhập sai thông tin hoặc thiết kế không nhất quán.

Lỗi 1 – Nhập sai WWPN

Expected:
10:00:00:90:AA:BB:CC:01
Configured:
10:00:00:90:AA:BB:CC:10

Server không thể nhìn thấy Storage.

Lỗi 2 – Zoning nhầm HBA

Server có:

HBA-A
HBA-B
nhưng zoning lại sử dụng nhầm WWPN.

Lỗi 3 – Chỉ cấu hình một path

Ví dụ:

ESXi
Fabric A
Storage
nhưng không có:
ESXi
Fabric B
Storage

Khi SAN Switch A gặp sự cố, host mất Storage.

Lỗi 4 – Zone quá rộng

Ví dụ:

Zone_BIG
ESXi01
ESXi02
ESXi03
DB01
DB02
Backup01
Storage01
Storage02
Storage03

Đây là thiết kế khó quản trị và không nên sử dụng trong môi trường Enterprise.

Lỗi 5 – Quên Activate Zone Set

Đã cấu hình:

Zone
Zone Set

nhưng chưa activate/commit cấu hình phù hợp.

Kết quả:

Configuration tồn tại
Configuration đang active
8. Thiết kế Zoning cho VMware

VMware là một trong những môi trường cần zoning rất rõ ràng.

Ví dụ:

ESXi 01
┌───────────┐
│ HBA-A HBA-B│
└───┬───┬───┘
│ │
┌────┘ └────┐
▼ ▼
Fabric A Fabric B
│ │
▼ ▼
Storage A Storage B
Ví dụ zoning:
Zone_ESX01_HBA_A_STG_A
Zone_ESX01_HBA_A_STG_B
Zone_ESX01_HBA_B_STG_A
Zone_ESX01_HBA_B_STG_B
Sau đó VMware sử dụng:

MPIO / NMP hoặc cơ chế multipathing tương ứng

để đảm bảo nhiều đường I/O tới Storage.

Điểm quan trọng:

Zoning không thay thế Multipathing.

Hai lớp này có vai trò khác nhau:

SAN Zoning
Cho phép HBA nhìn thấy Target
Storage Mapping / LUN Masking
Cho phép Host truy cập LUN
VMware Multipathing
Quản lý nhiều đường I/O

9. Thiết kế Zoning cho Database

Database Server thường có yêu cầu cao về:

  • Availability
  • Performance
  • Isolation
  • Predictable I/O path

Ví dụ:

DB Server
┌───────────┐
│ HBA-A HBA-B│
└───┬───┬───┘
│ │
▼ ▼
Fabric A/B
│ │
▼ ▼
SAN Storage
Không nên để Database Server nhìn thấy toàn bộ Storage Target của hệ thống.

Nên xác định rõ:

DB01
├── DATA LUN
├── LOG LUN
└── TEMP LUN
và kiểm soát:
Zoning
+
LUN Masking
+
Host Group
+
Multipathing
10. Thiết kế Zoning cho Backup

Backup thường có đặc điểm khác Database/VMware.

Ví dụ:

Backup Server
HBA
SAN Fabric
┌─────────┴─────────┐
▼ ▼
Production Backup Storage
Storage

Nếu Backup Server cần truy cập nhiều Storage, phải thiết kế Zone có kiểm soát.

Đặc biệt với môi trường backup lớn:

Production SAN
Backup Infrastructure
Backup Storage
cần tránh tình trạng Backup Server được cấp quyền nhìn thấy toàn bộ Storage không cần thiết.

11. Zoning và Storage Mapping là hai lớp khác nhau

Đây là điểm rất quan trọng khi troubleshooting.

Giả sử:

Server HBA
SAN Switch
Storage Target
Server nhìn thấy Storage Target chưa có nghĩa là Server có thể sử dụng LUN.

Phải qua thêm:

SAN Switch
Zoning
Storage Controller
LUN Masking
Host / Host Group
LUN
Do đó khi Server không thấy LUN, cần kiểm tra theo chuỗi:
HBA
FC Link
Fabric
Zoning
FC Login
Storage Target
LUN Masking
Host Mapping
Multipathing
OS / VMware

12. Case thực tế: Server → SAN → Storage

Giả sử triển khai một cụm VMware:

VMWARE CLUSTER
┌─────────────────────────┐
│ │
ESXi-01 ESXi-02
HBA-A HBA-B HBA-A HBA-B
│ │ │ │
│ │ │ │
▼ ▼ ▼ ▼
┌─────────┐ ┌─────────┐
│ Fabric A│ │ Fabric B│
│ SAN SW A│ │ SAN SW B│
└────┬────┘ └────┬────┘
│ │
│ │
└────────┐ ┌────────┘
▼ ▼
┌───────────────┐
│ SAN STORAGE │
│ Controller A/B│
└───────────────┘
Giả sử:
ESXi01 HBA-A
Fabric A
Storage Controller A
và:
ESXi01 HBA-B
Fabric B
Storage Controller B
Bước 1 – Xác định WWPN

Thu thập:

ESXi01_HBA_A
ESXi01_HBA_B
ESXi02_HBA_A
ESXi02_HBA_B
Storage_CTRL_A
Storage_CTRL_B
Bước 2 – Tạo Alias

Ví dụ:

ESX01_HBA_A
ESX01_HBA_B
ESX02_HBA_A
ESX02_HBA_B
STG01_CTRL_A
STG01_CTRL_B
Bước 3 – Tạo Zone
Zone_ESX01_A_STG01_A
ESX01_HBA_A
STG01_CTRL_A

và:

Zone_ESX01_B_STG01_B
ESX01_HBA_B
STG01_CTRL_B

Tương tự cho ESXi02.

Bước 4 – Tạo Zone Set

VMware_Production_ZoneSet
├── ESX01_A → STG01_A
├── ESX01_B → STG01_B
├── ESX02_A → STG01_A
└── ESX02_B → STG01_B

Bước 5 – Activate

Activate Zone Set trên Fabric tương ứng.

Bước 6 – Storage Mapping

Trên Storage:

Host Group
├── ESXi01
└── ESXi02
Datastore LUN
Bước 7 – VMware Multipathing

Cuối cùng VMware phải nhìn thấy nhiều path:

LUN
/ \
/ \
Path 1 Path 2
│ │
Fabric A Fabric B
│ │
HBA-A HBA-B
│ │
ESXi Host
Khi:
SAN Switch A DOWN
thì:
Fabric A ── X
Fabric B ── OK
VMware vẫn truy cập được Storage.

Đây mới là mục tiêu thực sự của thiết kế SAN HA.

13. Kiến trúc Zoning khuyến nghị

Có thể tóm tắt architecture chuẩn như sau:

STORAGE
┌──────────────┐
│ Controller A │
│ Controller B │
└──────┬───────┘
┌─────────┴─────────┐
│ │
Fabric A Fabric B
┌───────────┐ ┌───────────┐
│ SAN SW A │ │ SAN SW B │
└─────┬─────┘ └─────┬─────┘
│ │
HBA-A HBA-B
│ │
└────────┬───────────┘
ESXi / DB
Các lớp cần được thiết kế đồng thời:
┌──────────────────────────────┐
│ Application │
├──────────────────────────────┤
│ VMware / Database / Backup │
├──────────────────────────────┤
│ Multipathing │
├──────────────────────────────┤
│ LUN Masking / Host Mapping │
├──────────────────────────────┤
│ Zoning │
├──────────────────────────────┤
│ SAN Fabric │
├──────────────────────────────┤
│ FC Switch / FC HBA │
├──────────────────────────────┤
│ Storage Array │
└──────────────────────────────┘
Kết luận

Zoning không đơn giản là tạo một Zone để Server nhìn thấy Storage. Một thiết kế zoning tốt phải giải quyết đồng thời Security + Isolation + Availability + Scalability + Operations.

Nguyên tắc tôi khuyến nghị khi triển khai SAN Enterprise là:

WWPN-based zoning + Single Initiator/Single Target + Device Alias + Dual Fabric + Multipathing + LUN Masking.

Và quan trọng nhất:

Zoning quyết định “ai được nhìn thấy ai”; Storage Mapping quyết định “ai được phép sử dụng LUN nào”; Multipathing quyết định “I/O đi bằng đường nào và còn hoạt động thế nào khi một đường bị lỗi”.

Đây là ba lớp cần được thiết kế cùng nhau để tạo thành một kiến trúc SAN thực sự có HA, bảo mật và khả năng vận hành tốt.