Rủi ro khi sử dụng bộ nhớ động trong Hyper-V

Ảo hóa rất phổ biến đối với các tổ chức:nó cho phép họ sử dụng phần cứng tốt hơn bằng cách kết hợp nhiều máy chủ vào một máy chủ duy nhất, cung cấp khả năng HA và giảm các chi phí khác nhau như sưởi ấm / làm mát, giấy phép SQL Server và phần cứng. Tôi đã tham gia vào nhiều dự án với các tổ chức để giúp họ chuyển từ môi trường thực sang môi trường ảo và đã giúp họ trải nghiệm những lợi ích này.

Điều tôi muốn chia sẻ với bạn trong bài viết này là một vấn đề đặc biệt mà tôi đã gặp phải khi làm việc với Hyper-V trên Windows Server 2012 R2 bằng Bộ nhớ động. Tôi phải thừa nhận rằng hầu hết kiến ​​thức của tôi về ảo hóa đều thuộc về VMware, tuy nhiên điều đó hiện đang thay đổi.

Khi làm việc với SQL Server trên VMware, tôi luôn khuyên bạn nên đặt trước cho bộ nhớ, vì vậy khi tôi gặp tính năng Bộ nhớ động này với Hyper-V, tôi phải thực hiện một số nghiên cứu. Tôi đã tìm thấy một bài báo (Hướng dẫn cấu hình bộ nhớ động Hyper-V) giải thích nhiều lợi ích và yêu cầu hệ thống để sử dụng bộ nhớ động. Tính năng này khá thú vị trong cách bạn có thể cung cấp cho một máy ảo có bộ nhớ nhiều hơn hoặc ít hơn mà không cần phải tắt nguồn.

Chơi với Hyper-V Tôi thấy việc cung cấp các máy ảo rất đơn giản và dễ học. Với một chút nỗ lực, tôi đã có thể xây dựng một môi trường phòng thí nghiệm để mô phỏng trải nghiệm mà khách hàng của tôi đang có. Công lao dành cho sếp của tôi vì đã cung cấp cho tôi phần cứng tuyệt vời để làm việc cùng. Tôi đang chạy Dell M6800 với bộ xử lý i7, 32 GB RAM và hai ổ SSD 1TB. Con thú này tốt hơn rất nhiều máy chủ mà tôi đã từng làm việc.

Sử dụng VMware Workstation 11 trên máy tính xách tay của mình, tôi đã tạo khách Windows Server 2012 R2 với 4 vCPU, 24GB RAM và 100GB dung lượng lưu trữ. Sau khi khách được tạo và vá, tôi đã thêm vai trò Hyper-V và cấp phép khách dưới Hyper-V. Khách mới được xây dựng bằng Windows Server 2012 R2 với 2 vCPU, 22GB RAM và 60GB dung lượng lưu trữ chạy SQL Server 2014 RTM.

Tôi đã chạy ba bộ kiểm tra, mỗi bộ sử dụng bộ nhớ động. Đối với mỗi thử nghiệm, tôi đã sử dụng Trình tạo dữ liệu SQL của Red Gate dựa trên cơ sở dữ liệu AdventureWorks2014 để lấp đầy vùng đệm. Đối với thử nghiệm đầu tiên, tôi bắt đầu với 512MB cho giá trị RAM Khởi động vì đó là dung lượng bộ nhớ tối thiểu để khởi động Windows Server 2012 R2 và vùng đệm ngừng tăng ở mức khoảng 8GB.

Đối với mỗi bài kiểm tra, tôi sẽ cắt bớt bảng kiểm tra của mình, tắt máy khách, sửa đổi cài đặt bộ nhớ và bắt đầu sao lưu máy cho khách. Đối với thử nghiệm thứ hai, tôi đã tăng RAM khởi động lên 768MB và vùng đệm chỉ tăng lên kích thước chỉ hơn 12GB.

Đối với thử nghiệm thứ ba và cuối cùng, đã tăng RAM Khởi động lên 1024MB, chạy trình tạo dữ liệu và vùng đệm có thể tăng lên chỉ dưới 16GB.

Thực hiện một phép toán nhỏ về các giá trị này cho thấy rằng vùng đệm không thể phát triển nhiều hơn 16 lần RAM khởi động. Điều này có thể rất có vấn đề đối với SQL Server nếu RAM Khởi động nhỏ hơn 1/16 kích thước của bộ nhớ tối đa. Hãy nghĩ về một khách Hyper-V có RAM 64GB chạy SQL Server với giá trị RAM khởi động là 1GB. Chúng tôi đã quan sát thấy rằng vùng đệm sẽ không thể sử dụng nhiều hơn 16GB với cấu hình này, nhưng nếu chúng tôi đặt giá trị RAM Khởi động thành 4096MB thì vùng đệm sẽ có thể tăng lên 16 lần cho phép chúng tôi sử dụng tất cả 64GB.

Các tài liệu tham khảo duy nhất mà tôi có thể tìm thấy về lý do tại sao vùng đệm bị giới hạn ở mức 16 lần giá trị RAM Khởi động ở trang 8 và 16 trong sách trắng, Các phương pháp hay nhất để chạy SQL Server với HVDM. Tài liệu này giải thích rằng vì giá trị bộ nhớ đệm trong bộ đệm được tính vào thời điểm khởi động, nên nó là một giá trị tĩnh và không phát triển. Tuy nhiên, nếu SQL Server phát hiện ra rằng Hot Add Memory được hỗ trợ thì nó sẽ tăng kích thước dành riêng cho không gian địa chỉ ảo cho vùng đệm lên 16 lần so với bộ nhớ khởi động. Tài liệu này cũng nói rằng hành vi này ảnh hưởng đến SQL Server 2008 R2 trở về trước, tuy nhiên thử nghiệm của tôi được thực hiện trên Windows Server 2012 R2 với SQL Server 2014, vì vậy tôi sẽ liên hệ với Microsoft để được cập nhật tài liệu thực hành tốt nhất.

Vì hầu hết các DBA sản xuất không cung cấp máy ảo hoặc hoạt động nhiều trong không gian đó và các kỹ sư ảo hóa không nghiên cứu công nghệ SQL Server mới nhất và tuyệt vời nhất, tôi có thể hiểu thông tin quan trọng này về cách vùng đệm xử lý Bộ nhớ động mà nhiều người chưa biết. của người.

Ngay cả khi theo dõi các bài báo có thể gây hiểu lầm. Trong bài viết Hướng dẫn cấu hình bộ nhớ động Hyper-V, mô tả cho RAM khởi động có nội dung:

Sử dụng bộ nhớ tối ưu cho ai, chủ nhà hay khách? Nếu một quản trị viên ảo hóa đọc được thông báo này, họ có thể sẽ xác định rằng điều đó có nghĩa là bộ nhớ tối thiểu được phép khởi động hệ điều hành.

Chịu trách nhiệm về SQL Server có nghĩa là chúng ta cần biết về các công nghệ khác có thể ảnh hưởng đến môi trường của chúng ta. Với sự ra đời của SAN và ảo hóa, chúng ta cần hiểu đầy đủ mọi thứ trong những môi trường đó có thể tác động tiêu cực đến SQL Server như thế nào và quan trọng hơn là làm thế nào để truyền đạt mối quan tâm một cách hiệu quả đến những người chịu trách nhiệm về các hệ thống đó. Một DBA không nhất thiết phải biết cách cung cấp bộ nhớ trong SAN hoặc cách cung cấp hoặc có thể quản lý môi trường VMWare hoặc Hyper-V, nhưng họ nên biết những điều cơ bản về cách mọi thứ hoạt động.

Bằng cách biết những kiến ​​thức cơ bản về cách SAN hoạt động với các mảng lưu trữ, mạng lưu trữ, multi-pathing, v.v. cũng như cách hypervisor hoạt động với việc lập lịch cho CPU và phân bổ lưu trữ trong ảo hóa, DBA có thể giao tiếp và khắc phục sự cố tốt hơn khi có vấn đề . Trong nhiều năm, tôi đã làm việc thành công với một số quản trị viên SAN và ảo hóa để xây dựng các tiêu chuẩn cho SQL Server. Các tiêu chuẩn này là duy nhất cho SQL Server và không nhất thiết phải áp dụng cho máy chủ web hoặc ứng dụng.

Các DBA không thể thực sự dựa vào SAN và quản trị viên ảo hóa để hiểu đầy đủ các phương pháp hay nhất dành cho SQL Server, bất kể điều đó có tốt đẹp như thế nào, vì vậy chúng tôi cần tự đào tạo tốt nhất có thể về cách các lĩnh vực chuyên môn của họ có thể tác động đến chúng tôi.

Trong quá trình thử nghiệm của mình, tôi đã sử dụng một truy vấn từ bài đăng trên blog của Paul Randal, Các vấn đề về hiệu suất từ ​​bộ nhớ vùng đệm lãng phí, để xác định lượng vùng đệm mà cơ sở dữ liệu AdventureWorks2014 đang sử dụng. Tôi đã bao gồm mã bên dưới:

SELECT
    (CASE WHEN ([database_id] = 32767)
        THEN N'Resource Database'
        ELSE DB_NAME ([database_id]) END) AS [DatabaseName],
    COUNT (*) * 8 / 1024 AS [MBUsed],
    SUM (CAST ([free_space_in_bytes] AS BIGINT)) / (1024 * 1024) AS [MBEmpty]
FROM sys.dm_os_buffer_descriptors
GROUP BY [database_id];

Mã này cũng rất tốt để khắc phục sự cố cơ sở dữ liệu nào đang chiếm phần lớn vùng đệm của bạn, do đó bạn có thể biết cơ sở dữ liệu nào bạn nên tập trung vào việc điều chỉnh các truy vấn chi phí cao. Nếu bạn là cửa hàng Hyper-V, hãy kiểm tra với quản trị viên của bạn để xem liệu Bộ nhớ động có thể được định cấu hình theo cách ảnh hưởng tiêu cực đến máy chủ của bạn hay không.