Làm cách nào để dọn dẹp thủ công Công tắc ảo phân tán (VDS) trên máy chủ ESXi?
Nếu máy chủ ESXi được kết nối với Bộ chuyển mạch ảo phân tán-Distributed Virtual Switch (DVS) và bạn không thể xóa nó khỏi kho vCenter đúng cách, thao tác này sẽ dọn sạch VDS như một phần của quá trình xóa, thì bạn sẽ chỉ còn lại cấu hình VDS cũ. Nôm na bị mất kết nối vCenter và dạng trên host còn tồn tại các VDS trên host không xoá bằng vCenter được nên phải dùng cách này.
Tất nhiên, quy trình làm việc lý tưởng là dọn dẹp phần này trong vCenter Server nhưng nếu bạn bị mất quyền truy cập hoặc Máy chủ vCenter đã bị xóa và bạn có thể tự hỏi làm cách nào để dọn dẹp phần này theo cách thủ công?
Bước 0 – Đảm bảo rằng không có máy ảo hoặc giao diện VMKernel nào đang sử dụng tài nguyên DVS và Nhóm cổng phân phối (DVPG). Tạo lại vSphere Standard Switch (VSS) và các nhóm cổng tương ứng, đồng thời cấu hình lại các máy ảo và giao diện VMKernel của bạn trước khi tiếp tục. Nếu bạn cần hỗ trợ, vui lòng tìm kiếm trực tuyến vì có nhiều tài nguyên nêu rõ các bước này và điều này sẽ không được đề cập trong bài viết này.
Lưu ý: Về lý thuyết, sau Bước 0, về mặt kỹ thuật, bạn có thể chuyển sang Bước 5 và chỉ cần xóa cơ sở dữ liệu VDS nhưng tôi muốn dọn sạch tài nguyên trước bước đó nhưng điều này cũng có tác dụng nếu bạn đang gặp khó khăn.
Bước 1 – Chạy lệnh sau để liệt kê VDS hiện tại và các cổng đường lên liên quan đã được định cấu hình. Trong ví dụ bên dưới, tôi có một VDS có tên foo với một đường lên vmnic1 đang sử dụng cổng 9 . Môi trường của bạn có thể được định cấu hình khác nhau, vì vậy vui lòng ghi lại những giá trị này vì bạn sẽ cần nó trong các bước tiếp theo.
esxcfg-vswitch -l
Bước 2 – Xóa đường lên khỏi VDS bằng cách chạy lệnh sau và chỉ định đường lên, cổng đường lên và tên VDS.
Máy chủ đang chạy SQL Server bị ngắt điện đột ngột sẽ bị lỗi databases vì dữ liệu đang ghi log chưa checkpoint cho nên sẽ bị in recovery mode hoặc recovery pending.
Kết quả chúng ta không thể truy cập như hình.
Kiểm tra tình trạng hay trạng thái databases
SELECT name, state_desc from sys.databases
Dùng lệnh bên dưới để kiểm tra
Một số trạng thái của dữ liệu như sau:
ONLINE
RESTORING
RECOVERING
RECOVERY_PENDING
SUSPECT
EMERGENCY
OFFLINE
COPYING
OFFLINE_SECONDARY
Trạng thái chúng ta đang bị là Recovering
Nguyên nhân gây lỗi
Một số nguyên nhân sư sau:
Máy chủ SQL bị tắt do lỗi. Nó có thể là phần cứng, sức mạnh hoặc thứ gì khác.
Đĩa có thể bị thiếu.
Tệp MDF hoặc LDF có thể bị thiếu
Đĩa đầy
Quá trình nâng cấp SQL không diễn ra tốt đẹp hoặc bị gián đoạn.
Sự thay đổi lớn đang được đưa ra nhưng có điều gì đó đã thất bại giữa chừng, chẳng hạn như những thay đổi đối với tính năng FileStream.
Tệp LDF (nhật ký) bị hỏng.
Tệp MDF (dữ liệu) bị hỏng. Tệp db của tệp MDF có thể bị hỏng vì nhiều lý do như sự cố đĩa hoặc SAN, lỗi phần cứng, vi rút, v.v.
Máy chủ đã khởi động lại và có gì đó đã thay đổi, chẳng hạn như thiếu đĩa hoặc thư mục hoặc thiếu quyền.
Cryptoware đã mã hóa các tệp SQL của bạn.
Cách xử lý
Trường hợp 1: Set Database state to ONLINE
Lỗi do disk full thì không thể set online cũng như start chúng ta phải mở rộng disk trước khi thực hiện.
ALTER DATABASE ‘AdventureWorks2019’ SET ONLINE;
DBCC CHECKDB(‘AdventureWorks2019’) WITH NO_INFOMSGS;
Trường hợp 2: Rebuilding lại log file và detach và attach file
Nôm na là setup mode emergency, sau đó detach, attach lại.
ALTER DATABASE [AdventureWorks2019] SET EMERGENCY;
ALTER DATABASE [AdventureWorks2019] set MULTI_USER;
EXEC sp_detach_db '[AdventureWorks2019]';
EXEC sp_attach_single_file_db @DBName = '[AdventureWorks2019]', @physname = N'MDF_FILE_FULL_PATCH';
Trường hợp 3: Initiate DBCC CHECKDB with REPAIR option
Admin bị và xử lý theo cách 3 sẽ ok chúng ta có thể rơi vào từng trường hợp để test nhé.
Trường hợp này có thể bị mất dữ liệu, tốt nhất có thể chuẩn bị bản backup, trước khi thao tác.
Hãy chắc chắn rằng bạn có một bản sao lưu. Đừng làm điều này trên db DUY NHẤT mà bạn có, vì sau khi sửa chữa hoàn tất, bạn có thể mất dữ liệu và bạn có thể không thích những gì đã bị mất!
DBCC CHECKDB với tùy chọn SỬA CHỮA là một giao dịch được ghi lại và có thể phục hồi. Điều đó có ý nghĩa gì với bạn? Điều đó có nghĩa là nếu bạn gói DBCC CHECKDB với REPAIR vào một giao dịch (thực thi BEGIN TRANSACTION trước khi chạy lệnh) và bạn không thích kết quả cuối cùng, thì bạn có thể hoàn nguyên giao dịch và quay lại nơi bạn đã bắt đầu. Bằng cách đó, bạn sẽ có thể Khôi phục các thao tác sửa chữa nếu cần thiết.
3.1. REPAIR_REBUILD
Có nhiều cấp độ sửa chữa khác nhau. Hãy thử bắt đầu với “REPAIR_REBUILD”, thực hiện sửa chữa mà không có khả năng mất dữ liệu:
Đặt cơ sở dữ liệu ở chế độ một người dùng
Chạy DBBC CHECKDB với “REPAIR_REBUILD”
Đặt cơ sở dữ liệu thành “online” và kích hoạt lại chế độ nhiều người dùng
Câu lệnh bên dưới lưu ý thay databases của các bạn vào nhé:
ALTER DATABASE DATABASENAME SET SINGLE_USER;
DBCC CHECKDB (DATABASENAME, REPAIR_REBUILD) WITH NO_INFOMSGS, ALL_ERRORMSGS;
ALTER DATABASE [DATABASENAME] SET ONLINE;
ALTER DATABASE [DATABASENAME] SET MULTI_USER;
Nếu sửa chữa thành công, cơ sở dữ liệu có thể được đặt lại về chế độ nhiều người dùng. Nếu không, mức độ sửa chữa “REPAIR_ALLOW_DATA_LOSS” là tùy chọn tiếp theo.
3.2. REPAIR_ALLOW_DATA_LOSS
Bước này có thể bị mất dữ liệu nhé 😊
Đặt cơ sở dữ liệu ở chế độ Khẩn cấp
Chạy DBBC CHECKDB với “REPAIR_ALLOW_DATA_LOSS”
Đặt cơ sở dữ liệu thành “ONLINE” và kích hoạt lại chế độ nhiều người dùng
Code Sql:
ALTER DATABASE [DATABASENAME] SET EMERGENCY;
ALTER DATABASE [DATABASENAME] SET SINGLE_USER;
DBCC CHECKDB (DATABASENAME,REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS;
ALTER DATABASE [DATABASENAME] SET ONLINE;
ALTER DATABASE [DATABASENAME] SET MULTI_USER;
Check data
Kiểm tra lại trạng thái
Trường hợp 4: Restoring from Backup
Trường hợp này là sau cùng, các trường hợp trên không cứu được chúng ta buộc phải khôi phục từ backup.
Ngoài các công cụ sẵn có của MSSQL chúng ta có thể sử dụng áp thứ 3 trả tiền license để khôi phục hoặc sửa chữa:
When your memory ram becomes full, Windows moves data from your memory RAM to your hard drive, placing it in the page file (also known as the swap file).
SQL Server tends to go pear-shaped when it’s memory is paged to disk.
Optimal page file size settings for SQL Server
By default, the page file is auto managed by Windows.
You don’t want to trust the management of page file to Windows, as it won’t do what is optimal for SQL Server.
Page file sizing depends on the system crash dump setting requirements and the peak usage or expected peak usage of the System commit charge.
Both considerations are unique to each System, even for identical systems.
The old rules of thumb (Page file size = RAM * 1.5 or RAM * 2) makes no sense in modern systems, where the logic should be: the more RAM you have, the less you need paging file.
So, how should you size your Page File?
It depends on the specific workload and the type of server.
When sizing the page file, we need to consider our application’s memory needs and crash dump settings.
A good point of start is set 8-12 GB size for Kernel Memory dump on System with up to 256GB RAM.
You can learn more about it here.
How can I change the windows file size?
You can configure the page file by using System Properties:
DNS Requirements for the vCenter Server Appliance, lên DNS tạo các record A, PTR
Name vCenter Server 8
vcsa.viettechgroup.lab
IP: 172.16.23.3
Host Esxi or vCenter
IP: 172.16.1.1
If you want to deploy the appliance on an ESXi host, verify that the ESXi host is not in lockdown or maintenance mode and not part of a fully automated DRS cluster
Gồm 8 bước điền các thông tin như các bước chuẩn bị
B1: Introduction -> next
B2: End user license agreement-> Chọn chấp chập và next
Bước 3: Khai báo thông tin host esxi hoặc vcenter cần triển khai
Chọn Yes trust SSL
Bước 4: Khai báo VM tên và user root của VM VCSA
Bước 5: Để default tiny
Bước 6: Chọn Datastores cần Setup
Bước 7: Bước này quan trọng khai báo về port group VM network nào cần sử dụng để VM VCSA có thể liên hệ với ADDS, khi báo như hình tùy theo nhu cầu thực tế mạng của các bạn để gỏ vào.
Bước 8: chỉ là confirm các setting vừa rồi chọn finish
và quản lý vcenter https://ip:443 bằng vsphere client html5
Đây là quản lý máy ảo của VCSA 8 nhé
Tại đây có thể cập nhật các tùy chỉnh theo ý đồ quản trị
Lưu ý ae quản trị viên hay quên, nhớ cập nhật lại lại hệ thống password không là bị change password sau 90 ngày. 😊 Ở đây tùy ae nhé. Tôi thì có mình nên chơi never expires cho chắc ăn.
Mật khẩu vẫn để phức tạp đi
Cái quản trọng nữa là backup config sau khi cấu hình ngon lành để có trường hợp còn khôi phục lại nhé.
Microsoft Outlook Zero-Day Vulnerability- Elevation of Privilege Vulnerability CVE-2023-23397
Tóm tắt:
Microsoft giải thích: CVE-2023-23397 là một lỗ hổng EoP nghiêm trọng trong Microsoft Outlook, được kích hoạt khi kẻ tấn công gửi thư có thuộc tính MAPI mở rộng với đường dẫn UNC đến chia sẻ SMB (TCP 445) trên máy chủ do tác nhân đe dọa kiểm soát. Không cần tương tác người dùng,”
Cơ chế
Kẻ tấn công đã khai thác thành công lỗ hổng này có thể truy cập hàm băm Net-NTLMv2 của người dùng, có thể được sử dụng làm cơ sở cho một cuộc tấn công Chuyển tiếp NTLM chống lại một dịch vụ khác để xác thực là người dùng.
Preview Pane
Hacker tận dụng tính Preview Pane của email Outlook Email được chế tạo đặc biệt sẽ tự động kích hoạt khi nó được ứng dụng khách Outlook truy xuất và xử lý, cung cấp một vectơ tấn công lén lút để tin tặc khai thác. “Kẻ tấn công có thể khai thác lỗ hổng này bằng cách gửi một email được chế tạo đặc biệt, email này sẽ tự động kích hoạt khi nó được ứng dụng khách Outlook truy xuất và xử lý. Điều này có thể dẫn đến việc khai thác TRƯỚC KHI email được xem trong Preview Pane,”
Các phiên bản ảnh hưởng
Tất cả các phiên bản được hỗ trợ của Microsoft Outlook (2010, 2013,2016,2019, 365Apps)cho Windows đều bị ảnh hưởng.
Các phiên bản khác của Microsoft Outlook như Android, iOS, Mac, cũng như Outlook trên web và các dịch vụ M365 khác không bị ảnh hưởng.
Biện pháp làm khắc phục:
Thêm người dùng vào Nhóm bảo mật người dùng được bảo vệ (Protected Users Security Group), ngăn việc sử dụng NTLM làm cơ chế xác thực. Việc thực hiện giảm thiểu này giúp khắc phục sự cố dễ dàng hơn so với các phương pháp vô hiệu hóa NTLM khác.
Chặn TCP 445/SMB gửi đi từ mạng của bạn bằng cách sử dụng tường lửa vành đai(DMZ), tường lửa cục bộ và thông qua cài đặt VPN. Điều này sẽ ngăn việc gửi thông báo xác thực NTLM tới chia sẻ tệp từ xa.
Máy trạm Client
Yêu cầu tất cả máy trạm của Người dùng cuối cần upgrade Microsoft Outlook cho các Phiên bản:
Microsoft Outlook 2013 (64-bit edition):https://www.microsoft.com/en-us/download/details.aspx?id=105070
Microsoft Outlook 2016 (64-bit edition):https://www.microsoft.com/en-us/download/details.aspx?id=105058
Microsoft Office LTSC 2019/2021/365 for 64-bit editions:=> Cick upgrade