Dự phòng máy chủ SCADA: FactoryTalk View SE, AVEVA System Platform, Ignition và cách thử chuyển đổi

Dự phòng máy chủ SCADA (server redundancy) là có thêm một máy chủ thứ hai sẵn sàng nhận lại việc của máy thứ nhất: màn hình, kết nối dữ liệu tới bộ điều khiển, alarm và dữ liệu lịch sử. FactoryTalk View SE, AVEVA System Platform và Ignition đều làm việc này bằng một máy chính (primary) và một máy dự phòng (secondary hoặc backup) chạy trên hai máy tính riêng, và mỗi hãng đều ghi rõ phần nào chuyển sang máy kia khi chuyển đổi (switchover), phần nào thì không. Cặp máy chủ dự phòng chỉ bảo vệ lớp máy chủ; mạng, bộ điều khiển, nền tảng ảo hóa và historian phải được quyết định riêng.

Cái gì có thể hỏng, lớp nào che

Bảng dưới đối chiếu từng loại sự cố với lớp dự phòng mà tài liệu của hãng mô tả là che được sự cố đó.

FactoryTalk View SE: các cặp máy chủ dự phòng

Trong FactoryTalk View SE, dự phòng HMI server chỉ có ở ứng dụng network distributed. Một máy tính chạy HMI server chính, máy kia chạy HMI server dự phòng; khi máy chính không phục vụ được máy trạm (client) thì các client chuyển sang máy dự phòng và vẫn làm việc bình thường. Đồng hồ của hai máy phải được đồng bộ, và HMI server phải đặt chế độ nạp và chạy các thành phần khi Windows khởi động.

Trợ giúp của FactoryTalk Services Platform liệt kê các server làm dự phòng được: HMI server, và các data server như FactoryTalk Linx, OPC DA, Tag Alarm and Event, FactoryTalk Batch và OPC UA. Máy dự phòng không được chạy trên cùng máy tính với máy chính, hai máy phải cấu hình giống hệt nhau, và khi đã cấu hình xong thì mọi client trong ứng dụng đều dùng cặp này mà không phải cài thêm gì.

Hai thiết lập quyết định chuyện gì xảy ra sau sự cố:

• Tùy chọn chuyển đổi. Với FavorCurrent, mặc định cho HMI server mới, hệ thống ở lại trên máy dự phòng sau khi máy chính trở lại, cho tới khi người dùng chủ động chuyển hoặc máy đang active hỏng. Với FavorPrimary, máy chính nhận lại quyền ngay khi sẵn sàng.
• Giữ hai máy đồng bộ. FactoryTalk View Studio có thể lưu thay đổi online lên cả máy active lẫn standby và đồng bộ giá trị memory tag của HMI giữa hai máy; tab Redundancy còn có lệnh sao chép project từ máy active sang máy standby.

FactoryTalk Directory là chuyện riêng. Nếu máy chủ Network Directory không truy cập được, mỗi máy tính vẫn giữ một bản sao thông tin Directory: client đang chạy vẫn đọc ghi giá trị, xác nhận alarm và mở màn hình, nhưng không sửa được cấu trúc ứng dụng, chẳng hạn thêm hay sửa area, data server hoặc HMI server, cho tới khi Directory trở lại. Khi Directory và Activation server chạy trên máy chủ PlantPAx (PASS) trong cấu hình dự phòng, chúng chỉ nằm trên PASS chính; với kiến trúc phân tán, selection guide của PlantPAx khuyến nghị đặt Directory trên một máy chủ riêng. Trợ giúp của Rockwell còn nêu một ví dụ cặp máy tự chuyển về máy chính dù đã chọn "ở lại máy dự phòng": máy chính đang chứa Network Directory, một dịch vụ FactoryTalk chạy ngầm được tính là thêm một client, và dịch vụ giám sát tình trạng (health monitoring) chọn máy có nhiều client hơn.

AVEVA System Platform: AppEngine và nguồn dữ liệu dự phòng

AVEVA Application Server có dự phòng ở hai chỗ. Dự phòng AppEngine dùng một AppEngine chính và một AppEngine dự phòng do hệ thống tự tạo khi bật dự phòng, chạy trên hai WinPlatform đặt ở hai máy tính khác nhau cùng hệ điều hành. Dự phòng thu thập dữ liệu dùng hai DIObject làm nguồn dữ liệu và một RedundantDIObject theo dõi và chuyển qua lại giữa hai nguồn.

Khi chạy, cặp primary và backup đã cấu hình trở thành engine active và standby, và bên nào cũng có thể là active. Hai engine theo dõi nhau qua kênh thông điệp dự phòng (RMC), kênh này cũng lo việc trao đổi thông điệp và đồng bộ dữ liệu. Mỗi máy tính cần ít nhất hai card mạng: một cho mạng giám sát (supervisory network), một cho đường Ethernet nối riêng giữa hai máy. Thiết lập thư mục store-and-forward phải giống nhau trên cả hai WinPlatform.

Với dự phòng warm (warm redundancy), mặc định cho các cặp mới, engine standby khởi động và khởi tạo cùng lúc với engine active, các DI object đăng ký với cả hai, nên chuyển đổi nhanh hơn nhiều so với chế độ cũ (legacy), nơi engine standby chỉ khởi động khi xảy ra chuyển đổi. Engine standby nhận quyền sau thời gian Engine Failure Timeout, mặc định 30 giây, mà AVEVA lưu ý có thể cần chỉnh theo ứng dụng. Engine active bị hỏng sẽ khởi động lại và trở thành standby.

Về trend, InTouch HMI 2026 hỗ trợ một AVEVA Historian chính và một historian đối tác (partner); khi máy chính hỏng, InTouch đọc từ máy đối tác mà không phải sửa trend hay script.

Ignition: gateway master và backup

Dự phòng của Ignition là hệ hai nút: gateway master giữ cấu hình và gateway backup nhận cấu hình từ master. Trạng thái lúc chạy, như trạng thái alarm hiện hành, cũng được đồng bộ để backup nhận quyền với đúng trạng thái của master. Backup nối tới master qua Gateway Network, nên cổng này phải được mở qua mọi firewall nằm giữa hai máy.

• Mức hoạt động khi chờ (standby activity level). Backup cold kết nối tới OPC server nhưng không đăng ký giá trị tag, nên không tạo tải cho thiết bị nhưng chuyển đổi chậm hơn; backup warm chạy như nút active, chỉ không ghi dữ liệu lịch sử và không ghi xuống thiết bị.
• Chế độ phục hồi (recovery mode). Ở chế độ Automatic, master lấy lại quyền khi trở lại; ở chế độ Manual, backup vẫn active cho tới khi nó hỏng hoặc người dùng yêu cầu chuyển.
• Chế độ lịch sử (history mode). Full cho backup ghi lịch sử thẳng vào cơ sở dữ liệu và có thể sinh bản ghi trùng, vì backup không phân biệt được master đã chết hay chỉ mất liên lạc; Partial giữ dữ liệu lại và chỉ chuyển phần thu được trong lúc master thật sự dừng.

Cơ sở dữ liệu nằm ngoài cặp dự phòng. Tài liệu Ignition mô tả kết nối datasource có failover và lưu ý rằng mọi dữ liệu lịch sử đều đi qua Store and Forward, nên được giữ lại khi cơ sở dữ liệu không truy cập được. Gateway backup cần license riêng có cùng các module như master; nếu không, dữ liệu có thể mất khi chuyển đổi.

Ảo hóa: high availability và fault tolerance

Khi máy chủ SCADA chạy dưới dạng máy ảo (PlantPAx hỗ trợ VMware và Nutanix AHV), lớp ảo hóa có thêm các tùy chọn sẵn sàng của riêng nó. Hướng dẫn vSphere Availability của VMware mô tả hai mức:

• vSphere HA khởi động lại các máy ảo của một host bị hỏng trên các host khác trong cluster. VM Monitoring còn có thể khởi động lại máy ảo khi heartbeat của VMware Tools ngừng, và Application Monitoring khởi động lại máy ảo khi ứng dụng ngừng gửi heartbeat, việc này cần SDK của VMware hoặc ứng dụng có hỗ trợ.
• Fault Tolerance giữ một máy ảo thứ hai trên host khác luôn cùng trạng thái với máy ảo chính tới từng lệnh thực thi. Nếu một trong hai host hỏng, máy còn lại chạy tiếp, không mất dữ liệu và giữ nguyên kết nối mạng, rồi một bản sao mới được tạo.

Với HA, máy chủ khởi động lại trên host khác, nghĩa là ứng dụng SCADA cũng khởi động lại. VMware mô tả việc chuyển đổi của Fault Tolerance là phản ứng khi host hỏng; còn khi máy ảo hoặc ứng dụng ngừng phản hồi, vSphere HA có VM Monitoring và Application Monitoring để khởi động lại máy ảo. Hai lớp này kết hợp được với dự phòng ở mức ứng dụng: selection guide của PlantPAx tính tài nguyên sao cho hệ ba máy chủ dùng VMware HA hoặc Fault Tolerance vẫn chạy được trên hai máy sau một sự cố.

Historian: bộ đệm và bộ thu thập dự phòng

Chuyển đổi máy chủ không nên để lại khoảng trống trong dữ liệu lịch sử. Với FactoryTalk Historian SE, interface dự phòng thường đi cặp với dự phòng data server FactoryTalk Linx; hai nút interface phối hợp qua một file điều khiển failover đặt trên thư mục chia sẻ trong mạng, bộ đệm được cấu hình ở cả hai qua PI Buffer Subsystem, và bộ đệm nên nằm trên một ổ đĩa cục bộ khác ổ C. Selection guide PlantPAx bổ sung rằng historian dự phòng phải mua license cho số tag tương đương. Bộ đệm, giới hạn của bộ đệm và cách làm tương ứng của Ignition và AVEVA có trong bài historian là gì.

Mạng và bộ điều khiển

Máy chủ dự phòng không giúp được gì nếu switch duy nhất hoặc bộ điều khiển duy nhất bị hỏng. Selection guide PlantPAx khuyến nghị nguồn điện dự phòng và đường cáp vật lý tách riêng để không còn điểm hỏng đơn lẻ. PRP dùng gấp đôi cáp và thiết bị, thời gian phục hồi bằng không trong vùng PRP; DLR phục hồi sau một điểm đứt trên vòng trong 3 ms hoặc nhanh hơn. PlantPAx bắt buộc dùng module 1756-RM3 cho mọi cấu hình dự phòng ControlLogix. Xem DLR hay PRP và danh mục kiểm ControlLogix redundancy trước FAT.

Các trang dự án của TDL cho thấy những lớp này trên hệ Rockwell: ở Trạm phân phối khí Bà Rịa, hệ PLC-5 / RSView32 được chuyển sang ControlLogix dự phòng với FactoryTalk View SE server và client cùng remote I/O EtherNet/IP DLR; ở BSR, bốn hệ máy phát tua-bin hơi được chuyển từ ControlNet sang mạng EtherNet/IP dự phòng và từ RSView32 sang FactoryTalk View SE.

Người vận hành thấy gì khi chuyển đổi

Tài liệu của các hãng mô tả việc chuyển đổi từ phía client như sau:

• FactoryTalk View SE: client chuyển sang máy dự phòng và vẫn làm việc. Rockwell mô tả dự phòng của các alarm and event server, kể cả Tag Alarm and Event server, là tự động và trong suốt với client: người vận hành không phải làm gì và không phải khởi động lại phần mềm client. FactoryTalk System Status Portal hiển thị trạng thái từng server: Active, Standby, Failed, Transitioning…
• Ignition: client Vision tự nối sang nút kia và báo cho người dùng biết đã bị chuyển. Phiên Perspective thử nối lại gateway ban đầu trước; nếu backup lên active trước thì trình duyệt mở đúng project và trang đó trên backup.
• AVEVA System Platform: engine standby lên active sau thời gian timeout. AVEVA lưu ý script đọc attribute ngay sau chuyển đổi có thể thấy attribute còn đang khởi tạo, nên script loại này cần có logic thử lại.

Không tài liệu nào trong số này đưa ra thời gian chuyển đổi cho cả hệ thống. Hãy đo trên ứng dụng thật khi FAT và ghi lại.

Bài kiểm tra chuyển đổi khi FAT và SAT

1. Trạng thái ban đầu. Hai máy chủ ở đúng trạng thái Active và Standby, đồng hồ đã đồng bộ, các thay đổi online gần nhất có trên cả hai máy.
2. Chuyển tay. Chủ động đổi vai: lệnh Switchover từ một client FactoryTalk View SE, Request Failover của Ignition, hoặc forced failover trong System Platform. Trong FactoryTalk View SE, lệnh này bị bỏ qua nếu cặp máy đặt chế độ quay về máy chính.
3. Làm hỏng máy đang active. Tắt nguồn, rồi làm lại bằng cách rút cáp mạng giám sát. Kiểm tra màn hình, lệnh ghi xuống bộ điều khiển, trạng thái và xác nhận alarm trên mọi loại client.
4. Cho máy hỏng trở lại. Xác nhận chế độ quay về chạy đúng như đã cấu hình, và tìm các client ẩn như dịch vụ Directory trên máy chính.
5. Dừng máy chủ FactoryTalk Directory (hệ Rockwell). Client đang chạy phải làm việc bình thường; việc thêm hay sửa area và server phải chờ Directory trở lại.
6. Cắt đường tới historian. Khởi động lại bộ thu thập đang active (interface chính) vài lần như hướng dẫn Historian SE của Rockwell gợi ý, và kiểm tra việc thu thập vẫn tiếp tục. Sau đó ngắt kho historian một lúc, nối lại và kiểm tra dữ liệu trong bộ đệm đã về đủ.
7. Làm hỏng một host ảo hóa. Xác nhận máy ảo SCADA khởi động lại (HA) hay chạy tiếp (Fault Tolerance), và cặp ứng dụng phản ứng ra sao.
8. Khởi động lại một nút dự phòng. Với System Platform, AVEVA cảnh báo khởi động lại khi đang rút mạng chính có thể làm mạng chính gắn vào địa chỉ IP của RMC; kiểm tra lại kết nối mạng sau mỗi lần khởi động.

Nếu có firewall giữa các máy chủ, xem firewall hệ FactoryTalk mở đúng cổng; nếu client không vào được máy chủ sau chuyển đổi, bắt đầu từ FactoryTalk View SE: máy trạm không kết nối. Công việc của TDL trên các nền tảng này có ở trang SCADA và historian và nâng cấp hệ Rockwell.