Database
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Database

Tầm quan trọng của việc chọn kích thước máy ảo Azure thích hợp

Di chuyển phiên bản SQL Server tại chỗ sang Máy ảo Azure (VM) là một phương pháp phổ biến để di chuyển sang Azure. Các chuyên gia CNTT đã quen thuộc với việc xác định phạm vi kích thước của máy ảo liên quan đến vCPU, bộ nhớ và dung lượng lưu trữ. Microsoft cung cấp nhiều loại máy ảo và kích thước cho nhu cầu của tổ chức. Bạn sẽ thấy các loại được tham chiếu là Family trong Cổng Azure khi định cỡ máy ảo.

Các loại và kích thước máy ảo

Microsoft đã giúp đơn giản hóa mọi thứ bằng cách tạo ra nhiều loại máy ảo. Các loại này hướng tới việc xác định máy móc theo mục đích. Các loại khác nhau là:

  • Mục đích chung - Tỷ lệ CPU trên bộ nhớ cân bằng, cơ sở dữ liệu vừa và nhỏ
  • Được tối ưu hóa cho máy tính - Tỷ lệ CPU trên bộ nhớ cao, máy chủ web và máy chủ ứng dụng có lưu lượng truy cập trung bình
  • Bộ nhớ được tối ưu hóa - Tỷ lệ bộ nhớ trên CPU cao, máy chủ cơ sở dữ liệu quan hệ, bộ nhớ đệm trung bình đến lớn và phân tích trong bộ nhớ
  • Bộ nhớ được tối ưu hóa - Thông lượng đĩa và IO cao
  • GPU - Kết xuất đồ họa nặng và chỉnh sửa video
  • Máy tính hiệu suất cao - Máy ảo CPU nhanh nhất và mạnh nhất

Trong mỗi loại / họ có nhiều kích cỡ để lựa chọn. Kích thước cung cấp cho bạn các tùy chọn về số lượng vCPU, RAM và đĩa dữ liệu. Số lượng đĩa dữ liệu sẽ xác định IOPS tối đa (IOPS là viết tắt của hoạt động đầu vào / đầu ra mỗi giây.) Và kích thước tổng thể sẽ xác định dung lượng lưu trữ tạm thời có sẵn. Một số kích thước nhất định cũng hỗ trợ lưu trữ cao cấp, đây là yêu cầu đối với SQL Server sản xuất.

Tùy chọn Hình ảnh VM

Khi chọn một hình ảnh cho SQL Server, bạn có một số tùy chọn. Bạn có thể chọn chỉ chọn hệ điều hành, chẳng hạn như Linux hoặc Windows, hoặc bạn có thể chọn để chọn một hình ảnh với hệ điều hành và SQL Server đã được cài đặt. Hiện tại tôi thích chọn hình ảnh chỉ với hệ điều hành để tôi có thể cài đặt SQL Server và cấu hình nó theo cách tôi muốn. Khi bạn chọn hình ảnh thư viện có cài đặt sẵn SQL Server, tất cả các thành phần có trong ISO cho phiên bản đó đều được cài đặt và tôi không phải lúc nào cũng cần cài đặt Dịch vụ tích hợp hoặc Dịch vụ phân tích.

Cân nhắc về kích thước máy ảo

Việc chọn máy ảo Azure có vẻ dễ hiểu, với việc chọn kích thước dựa trên số lượng vCPU, bộ nhớ và đủ dung lượng để chứa cơ sở dữ liệu của bạn, tuy nhiên, tôi thấy khách hàng gặp vấn đề về hiệu suất liên quan đến lưu trữ. Xu hướng phổ biến là chọn một máy ảo chỉ dựa trên vCPU, bộ nhớ và dung lượng lưu trữ mà không đánh giá tiêu chuẩn IO và yêu cầu thông lượng hiện tại. Khi bạn tạo một máy ảo Azure trong Azure Portal, bạn có thể lọc các tùy chọn dựa trên những điều sau:

  • Kích thước
  • Thế hệ
  • Gia đình
  • RAM / bộ nhớ
  • Hỗ trợ bộ nhớ đặc biệt
  • Số lượng vCPU
  • Đĩa hệ điều hành tạm thời

Khi bạn chọn các tùy chọn bộ lọc của mình, nếu có, bạn sẽ thấy danh sách các máy chủ có sẵn. Trong danh sách, nó hiển thị Kích thước máy ảo, cung cấp, họ, vCPU, RAM, số lượng đĩa dữ liệu được hỗ trợ, IOPS tối đa, bộ nhớ tạm thời (D :), nếu đĩa cao cấp được hỗ trợ và chi phí ước tính. Tôi đã lọc phần sau trên đĩa cao cấp được hỗ trợ và kích thước bắt đầu bằng chữ E để bộ nhớ được tối ưu hóa.

Tuy nhiên, những gì không được hiển thị là lượng thông lượng cho phép trên mỗi máy ảo. Thông lượng đo tốc độ truyền dữ liệu đến và đi từ phương tiện lưu trữ tính bằng megabyte mỗi giây.

Thông lượng có thể được tính bằng công thức sau

MB / s =IOPS * KB mỗi IO / 1.024

Sử dụng công thức này, KB mỗi IO sẽ là kích thước khối của bạn. Nếu bạn đang định dạng dữ liệu và ổ ghi nhật ký của mình ở 64k, thì công thức cho các máy ảo E2s_v3, E4-2s_v3 và E8-2s_v3 với 3.200, 6.400 và 12.800 IOPS sẽ là:

MB / s =3.200 * 64 / 1.024 hoặc 200 MB / s
MB / s =6.400 * 64 / 1.024 hoặc 400 MB / s
MB / s =12.800 * 64 / 1.024 hoặc 800 MB / s

Các tính toán thông lượng dựa trên IOPS của mỗi máy ảo có kích thước khối 64k không quá tệ. Những con số này không tính đến bất kỳ hình phạt ghi nào đối với RAID. Tôi đặt từng máy ảo này để thử nghiệm bằng CrystalDiskMark. Những con số tôi nhận được về thông lượng không giống với những gì các phép tính đang ước tính.

Kiểm tra điểm chuẩn

Tôi đã cung cấp ba máy ảo thuộc cùng một họ, tuy nhiên kích thước khác nhau và mỗi máy có 2 vCPU. Các thông số kỹ thuật của máy ảo là:

  • E2s_v3 - 2 vCPU - 16GB RAM - 3.200 IOPS - Hỗ trợ tối đa 4 đĩa dữ liệu
  • E4-2s_v3 - 2 vCPU - 32GB RAM - 6.400 IOPS - Hỗ trợ tối đa 8 đĩa dữ liệu
  • E8-2s_v3 - 2 vCPU - RAM 64GB - 12.800 IOPS - Hỗ trợ tối đa 16 đĩa dữ liệu
  • Đĩa dữ liệu P60 - SSD cao cấp - 16.000 IOPS

Trên mỗi máy ảo, tôi cung cấp một đĩa cao cấp P60 với dung lượng 8TB. Đĩa này đã quảng cáo 16.000 IOPS với kích thước khối 64k có thể hỗ trợ thông lượng 1.000 MBps, tuy nhiên, tài liệu Azure cho biết đĩa cung cấp thông lượng 500 MBps.

CrystalDiskMark là một công cụ điểm chuẩn ổ đĩa mã nguồn mở dành cho Windows và nó dựa trên công cụ Diskspd của Microsoft. Công cụ đo lường hiệu suất tuần tự và ngẫu nhiên của các lần đọc và ghi.

Trên đầu công cụ là một số trình đơn thả xuống. Số 5 là số lần lặp lại bài kiểm tra sẽ được chạy. Tiếp theo là 1GiB, đây là kích thước của tệp thử nghiệm. Đối với một thử nghiệm sản xuất thực sự, điều này phải đủ lớn để tránh đánh vào bộ nhớ cache. Phiên bản 7.0 hỗ trợ tối đa một tệp 64 GiB. Cuối cùng là ổ đĩa mà bạn muốn thực hiện kiểm tra.

Khi bạn đã lựa chọn xong, bạn có thể nhấp vào Tất cả để bắt đầu chuỗi thử nghiệm. Bài kiểm tra sẽ lặp lại qua các hoạt động đọc / ghi tuần tự và ngẫu nhiên khác nhau. Hãy thận trọng nếu bạn định đánh giá các máy chủ sản xuất thực. Thử nghiệm này đặt một tải lên đĩa của bạn và có thể tác động đáng kể đến khối lượng công việc sản xuất. Sau giờ hoặc trong thời gian bảo trì sẽ được ưu tiên hơn.

Tôi đã chọn chạy 5 lần lặp lại bài kiểm tra với tệp 32 GiB trên đĩa P60 là ổ E:.

Máy ảo E2s_v3 đạt tối đa dưới 50 MBps, thấp hơn 200 MB mà chúng tôi đã tính toán.

Máy ảo E4-2s_v3 đạt tối đa dưới 100 MBps thay vì 400 MBps.

Máy ảo E8-2s_v3 đạt tối đa dưới 200 MBps thay vì 800 MBps ước tính.

Tại sao thông lượng lại thấp hơn?

Dựa trên các tính toán trước đó của tôi, 3.200 IOPS ở kích thước khối 64k sẽ tạo ra thông lượng 200MB, nhưng tôi không thấy các con số gần với mức đó cho đến khi tôi có đĩa 16.000 IOPS trên máy ảo hỗ trợ lên đến 12.800 IOPS. Lý do là mỗi kích thước VM có một giới hạn cho thông lượng. Nếu bạn xem tài liệu về dòng máy ảo được tối ưu hóa bộ nhớ, bạn sẽ thấy rằng thông lượng đĩa chưa được lưu trữ tối đa của E2s là 3.200 IOPS / 48 MBps, thông lượng đĩa chưa được lưu trữ tối đa của E4s là 6.400 IOPS / 96 MBps và đĩa chưa được lưu trữ tối đa của E8s thông lượng là 12.800 IOPS / 192 MBps. Những con số này trùng khớp với kết quả tôi thu được khi sử dụng CrystalDiskMark.

Mặc dù bạn có thể phân bổ các đĩa rất lớn có nhiều IOPS và hỗ trợ số lượng thông lượng cao, nhưng kích thước VM rất có thể hạn chế thông lượng của bạn.

Đánh giá điểm chuẩn nhu cầu thông lượng hiện tại của bạn nên là một ưu tiên lớn trước khi chuyển bất kỳ khối lượng công việc SQL Server nào sang Azure.

Kết luận

Tôi hiểu rằng IOPS là một đơn vị đo lường mà các nhà sản xuất đĩa và nhà cung cấp dịch vụ lưu trữ cung cấp và điều đó không sao cả. Tuy nhiên, khi nói đến thử nghiệm lưu trữ, chúng tôi có xu hướng tập trung nhiều hơn vào số lượng thông lượng. Nó chỉ là một vấn đề toán học, nhưng trừ khi bạn đang kinh doanh lưu trữ điểm chuẩn và thực hiện các phép tính từ IOPS đến thông lượng dựa trên kích thước khối, nó có thể gây nhầm lẫn.

Điều gây phiền hà đối với tôi là thực tế là hạn chế về thông lượng không rõ ràng khi bạn chọn kích thước máy ảo. Đơn vị đo IO lưu trữ là IOPS. Ở 3.200 IOPS với kích thước khối 64k, tôi có thể đạt khoảng 200 MBps tuy nhiên máy ảo của tôi bị giới hạn ở 48 MBps. Nhiều chuyên gia CNTT đã phát hiện ra rằng họ có vấn đề về hiệu suất đĩa và mở rộng bộ nhớ của họ lên đĩa lớn hơn và nhanh hơn (nhiều IOPS hơn) với mong muốn hiệu suất tốt hơn, nhưng họ nhận thấy rằng nó không giải quyết được vấn đề của họ. Vấn đề là kích thước của máy ảo đã hạn chế thông lượng của chúng. Mở rộng quy mô lên một máy ảo có kích thước cao hơn sẽ giải quyết được vấn đề, nhưng điều đó đi kèm với chi phí. Trong ví dụ của tôi, E4 đắt gấp đôi E2, tuy nhiên, nó tăng gấp đôi bộ nhớ và thông lượng, trong khi vẫn giữ nguyên vCPU. E8 có chi phí gấp đôi E4 và tăng gấp đôi thông lượng và bộ nhớ, trong khi vẫn giữ nguyên vCPU. Duy trì cùng một số lượng vCPU có nghĩa là tôi sẽ không bị tăng chi phí giấy phép SQL Server cốt lõi.

Cuối cùng, bạn cần phải chuẩn hóa các yêu cầu thông lượng hiện tại của mình và đảm bảo định cỡ máy ảo Azure hoặc bất kỳ máy ảo nào phù hợp với nhu cầu của bạn. Đừng chỉ tập trung vào điểm chuẩn của bộ nhớ cục bộ, hãy phân tích khối lượng công việc của bạn cần và kích thước phù hợp.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Không gian bảng SYSMGMTDATA là ĐẦY ĐỦ trong Kho lưu trữ Quản lý Cơ sở Hạ tầng Lưới (MGMTDB)

  2. Kiểm tra tác động hiệu suất của khối lượng công việc Adhoc

  3. SQL SELECT cho người mới bắt đầu

  4. Cách đọc và diễn giải lỗi SQL

  5. Toán tử SQL LIKE cho người mới bắt đầu