Cách đây tầm nửa tháng, tôi có thực hiện triển khai Kaspersky Security Center (KSC) phiên bản 14 cho nhánh Hà Nội, chỉ khoảng vài trăm người dùng, không nhiều. Dùng từ “triển khai” nghe có vẻ to lớn, nhưng thật ra tôi cũng chưa biết dùng từ nào thích hợp hơn. Nói khiêm tốn thì người bĩu môi bảo tầm thường, nói vĩ mô quá thì người cười khẩy bảo tự phụ.
Hệ thống hiện tại cài đặt khá… hỗn hợp, khi mà nhiều dịch vụ chia sẻ gom chung một máy chủ Windows Server 2008 R2. Phiên bản KSC đang sử dụng là 12.0, nhưng license mới lại là Kaspersky Endpoint Detection and Response Optimum (EDR), không phải là Kaspersky Endpoint Security for Windows (KES) như trước nữa. Câu chuyện sẽ chẳng có gì đáng để lưu ý lắm, nếu như bản EDR này không đòi KSC phải ít nhất 12.1.
Đọc thêm tài liệu thì tôi thấy cũng không đáng để níu kéo thêm với KSC 12 nữa.
Phương án chốt hạ sẽ là đẩy lên bản KSC 14 mới nhất đang được Kaspersky hỗ trợ và tương thích nhất với EDR!
Câu chuyện tiếp theo lại cũng không kém phần buồn cười. Theo yêu cầu của Kaspersky, VM chạy được KSC 14 ổn định, nếu là VMware vSphere, thì bắt buộc phải là ESXi 6.7 trở lên.
Máy chủ đáp ứng được điều đó thì không đủ ổ cứng lẫn tài nguyên CPU hay RAM. Máy chủ dư rất nhiều thì lại đang chạy ESXi 6.5 bản cũ nhất. Đời luôn có cách hay để đẩy ta vào con đường cụt.
Đầu tiên, tôi thử cố tình bỏ qua yêu cầu này, vì nghĩ rằng đôi khi triển khai ta có thể bypass một số yêu cầu mà vẫn đảm bảo được kết quả như mong muốn. Nhưng rồi hậu quả đến chỉ sau 1 ngày rưỡi chạy liên tục. VM của máy chủ KSC 14 sẽ liên tục bị treo với hiện tượng đơ màn hình, đen màn hình, lỗi Kernel-Power với Event ID là 41. Sẵn đây, tôi cũng muốn nói thêm, nếu muốn triển khai cái gì trên Windows mà bớt khổ, tốt nhất là cứ tập xài thành thạo và nhớ càng nhiều càng tốt Event ID trong Event Viewer của Windows.
Sau khi tìm một vòng khắp Google, Bing,… không ra kết quả gì, ngoài một mục nhỏ trong diễn đàn của Kaspersky: https://forum.kaspersky.com/topic/kav-makes-my-windows-10-1903-bsod-solvedclosed-1362/
Thật ra thì cái post đó cũng chẳng liên quan gì lắm tới câu chuyện tôi đang gặp.
Vẫn tiếp tục kiên trì đọc thêm, tôi phát hiện ra, rất có thể lỗi treo này liên quan SQL Server 2019 mà tôi cài chung với máy chủ đang có vấn đề về phiên bản dưới cumulative patch CU12:
https://support.kaspersky.com/ksc/14/en-US/92235.htm
Sử dụng SSMS của Microsoft để kết nối tới Database của KSC 14, chạy lệnh như trong bài viết của Kaspersky hướng dẫn. Tới đây thì tôi thấy có vẻ mọi thứ đã ổn hẳn, đúng là tài nguyên máy có tuột thấp hơn so với logs ghi nhận mỗi lần sắp lỗi là máy sẽ high resources gây treo.
Nhưng thật ra là do tôi ăn dưa bở thôi.
Sau khi chạy được tiếp gần đủ 2 ngày, máy chủ KSC 14 lại tiếp tục bị treo…
Lần này thì dù bao biện như thế nào, bất chấp kinh nghiệm cài và tối ưu máy chủ trong suốt hơn 4 năm có lẻ, nhưng thật sự không còn gì để thừa nhận là chính việc ngoan cố cài trên ESXi 6.5 không được support của KSC 14 đã liên tục làm crash kernel của OS.
Thôi thì bắt tay vào sửa từ gốc rễ vấn đề: nâng cấp nền ảo hóa của máy chủ vật lý lên 6.7 thôi!
Tại sao lại là ESXi 6.7 thôi mà không phải là 7.0 hoặc 8.0 (tính theo thời điểm của bài viết này thì 8.0 đang là latest version)??? Câu trả lời nằm ở con chipset CPU của máy chủ vật lý chỉ hỗ trợ được tới 6.7 latest version mà thôi. Không phải phán bừa gì, ta có cách để kiểm tra chính thức đàng hoàng: https://www.vmware.com/resources/compatibility/search.php
Vậy thì tải bản cập nhật về và chạy thôi nào!
Nếu là game tới đây dễ quá thì chẳng còn gì để viết. Nhưng để nâng cấp nền ảo hóa và khởi động lại cho một máy chủ vật lý chạy kha khá VMs quan trọng trên đó, mà cụ thể là AD và File Server, thì không phải là câu chuyện tôi muốn là xử liền được. Phương án backup vốn vẫn có sẵn từ lâu và vẫn chạy ổn định mỗi ngày, nhưng có gì đảm bảo tôi upgrade xong có lỗi mà có thể khôi phục VM lại với thời gian tối ưu và nhanh nhất có thể? Vậy là phải kiểm tra tiếp. Với AD, chỉ vài trăm GB, tôi có thể làm một cách an toàn nhất với mong muốn là export ra OVF. Còn với File Server tính bằng TB, tôi chọn cách replicate qua máy chủ còn lại.
Trong hàng vô vàn cách để replicate files với đầy đủ hiện trạng thuộc tính, phân quyền,… thì tôi chọn Vice Versa Pro. Dự tính chỉ cần chạy nhiều nhất 4 ngày liên tục là xong, tiếp theo là dùng VVEngine để replicate files theo thời gian thực cho tới tận đêm tôi bắt đầu nâng cấp ESXi.
Nghe đoạn trên thì có vẻ nhanh gọn nhưng thật ra nếu cấu hình trật profiles thì cũng không vui lắm =))
Sau khi đã chuẩn bị xong xuôi hết tất thảy: môi trường, VMs, replication, sources nâng cấp,.. thì ta tiến hành làm. Để đỡ phức tạp nhất, ta nên chọn cách bỏ gói nâng cấp lên Datastore của server cần nâng cấp, rồi thông qua giao thức SSH mà chạy lệnh nâng cấp thì sẽ đơn giản nhất.
Lưu ý: Lệnh nâng cấp Build cho cùng một đời phiên bản và lệnh nâng cấp lên đời cao hơn là khác nhau nhé.
Nếu không có gì lỗi lầm, nhưng thật ra như trường hợp của tôi chạy lệnh là có. Không hiểu vì sao gói nâng cấp nằm trong đúng lộ trình đi lên của phiên bản hiện tại, nhưng tôi chạy lệnh liên tục ra lỗi không đọc được manifest trong gói. Nếu đã lâm tới đường này, ta có thể chạy lệnh upgrade online.
Và nếu thuận lợi, sau khi máy chủ vật lý reboot lại xong, phiên bản mới đã được cập nhật thành công.
Mọi chuyện quay lại việc cài KSC 14, lấy Polices và Tasks của bên KSC 12 cũ mang qua import vào. Để đơn giản nhất, ta cũng nên cài thêm KSC Web Console để tiện quản lý, bên cạnh Administration Console.
Còn những việc nhỏ trong suốt quá trình thực hiện sẽ xảy ra nữa. Những chuyện như thế đòi hỏi phải bình tĩnh, có kĩ năng Google search nhanh, khả năng đọc logs và kinh nghiệm để phán đoán rồi xử lý cho nhanh gọn.
VÕ TÌNH THƯƠNG