Phiên bản quản lý cơ sở dữ liệu Azure SQL nói chung trở nên khả dụng vào cuối năm 2018. Kể từ đó, nhiều tổ chức đã bắt đầu chuyển sang Phiên bản được quản lý vì những lợi ích của môi trường được quản lý. Các tổ chức đang tận dụng lợi thế của việc có các bản sao lưu được quản lý, nhiều tính năng bảo mật tích hợp, SLA thời gian hoạt động là 99,99% và môi trường luôn cập nhật, nơi họ không còn chịu trách nhiệm vá SQL Server hoặc hệ điều hành.
Một kích thước không không luôn phù hợp với tất cả. Phiên bản được quản lý cung cấp hai cấp cho hiệu suất. Mục đích chung tier được thiết kế cho các ứng dụng có yêu cầu về hiệu suất và độ trễ I / O điển hình, đồng thời cung cấp HA tích hợp sẵn. Quan trọng kinh doanh tier được thiết kế cho các ứng dụng yêu cầu độ trễ I / O thấp và yêu cầu HA cao hơn. Business Critical cũng cung cấp hai tạp chí thứ hai không đọc được và một phụ lục có thể đọc được. Thứ cấp có thể đọc được là một cách tuyệt vời để phân phối khối lượng công việc của chính, có thể hạ thấp cấp dịch vụ cần thiết cho cấp chính - làm giảm chi tiêu tổng thể cho ví dụ.
Khi Phiên bản được quản lý lần đầu tiên được phát hành, bạn có thể chọn giữa các bộ xử lý Gen4 và Gen5. Gen4 vẫn được mô tả trong tài liệu, nhưng tùy chọn này hiện hầu như không khả dụng. Đối với bài viết này, tôi sẽ chỉ đề cập đến các cấu hình sử dụng bộ xử lý Gen5.
Mỗi cấp dịch vụ hỗ trợ từ 4 đến 80 CPU logic - còn được gọi là lõi ảo hoặc vCores. Bộ nhớ được cấp phát khoảng 5,1 GB cho mỗi vCore. Mục đích chung cung cấp lên đến 8 TB dung lượng lưu trữ Azure Blob hiệu suất cao, trong khi Business Critical cung cấp tới 4 TB dung lượng lưu trữ SSD cục bộ siêu nhanh.
Bộ nhớ
Với việc chỉ có 5,1 GB bộ nhớ cho mỗi vCore, một phiên bản có ít vCore hơn có thể gặp khó khăn. Các tùy chọn cho cấu hình vCore là 4, 8, 16, 24, 32, 40, 64 và 80 vCore. Nếu bạn thực hiện phép toán trên từng tùy chọn vCore ((number of vCores) × (5.1 GB) ), bạn sẽ nhận được các kết hợp lõi / bộ nhớ sau:
4 vCores = 20.4 GB 8 vCores = 40.8 GB 16 vCores = 81.6 GB 24 vCores = 122.4 GB 32 vCores = 163.2 GB 40 vCores = 204.0 GB 64 vCores = 326.4 GB 80 vCores = 408.0 GB
Đối với nhiều tổ chức, tôi đã giúp chuyển đổi từ tại chỗ sang Phiên bản được quản lý, tôi đã thấy bộ nhớ giảm đáng kể. Các cấu hình tiêu biểu tại chỗ sẽ là 4 vCores và 32 GB bộ nhớ hoặc 8 vCores và 64 GB. Cả hai đều làm giảm hơn 30% bộ nhớ. Nếu phiên bản đã bị áp lực bộ nhớ, điều này có thể gây ra sự cố. Trong hầu hết các trường hợp, chúng tôi đã có thể tối ưu hóa phiên bản tại chỗ để giúp giảm bớt áp lực bộ nhớ trước khi chuyển sang Phiên bản được quản lý, nhưng trong một số trường hợp, khách hàng phải sử dụng phiên bản vCore cao hơn để giảm bớt áp lực bộ nhớ .
Bộ nhớ
Lưu trữ khó khăn hơn một chút để lập kế hoạch và cân nhắc, do phải xem xét nhiều yếu tố. Để lưu trữ, bạn cần tính đến yêu cầu lưu trữ tổng thể cho cả kích thước lưu trữ và nhu cầu I / O. Cần bao nhiêu GB hoặc TB cho phiên bản SQL Server và tốc độ lưu trữ cần thiết là bao nhiêu? Phiên bản tại chỗ đang sử dụng bao nhiêu IOPS và bao nhiêu thông lượng? Đối với điều đó, bạn phải căn cứ vào khối lượng công việc hiện tại của mình bằng perfmon để ghi lại MB / s trung bình và tối đa và / hoặc chụp nhanh sys.dm_io_virtual_file_stats để nắm bắt việc sử dụng thông lượng. Điều này sẽ cung cấp cho bạn ý tưởng về loại I / O và thông lượng bạn cần trong môi trường mới. Một số khách hàng mà tôi đã làm việc đã bỏ lỡ phần quan trọng này của kế hoạch di chuyển và gặp phải các vấn đề về hiệu suất do chọn cấp phiên bản không hỗ trợ khối lượng công việc của họ.
Điều này rất quan trọng đối với đường cơ sở vì với các máy chủ tại chỗ, thông thường lưu trữ được cung cấp từ một SAN siêu nhanh với khả năng thông lượng cao đến các máy ảo có kích thước nhỏ hơn. Trong Azure, IOPS và giới hạn thông lượng của bạn được xác định bởi kích thước của nút máy tính và trong trường hợp Quản lý phiên bản, nó được xác định bởi số vCores được phân bổ. Đối với Mục đích chung, giới hạn là 30-40k IOPS mỗi trường hợp hoặc 500 đến 12.500 IOPS cho mỗi tệp tùy thuộc vào kích thước tệp. Thông lượng trên mỗi tệp cũng dựa trên kích thước khác nhau, bắt đầu từ 100 MiB / giây cho tệp lên đến 128 GB và lên đến 480 MiB / giây cho tệp 4 TB trở lên. Trong quan trọng kinh doanh, IOPS dao động từ 5,5 nghìn - 110 nghìn mỗi trường hợp hoặc 1,375 IOPS cho mỗi vCore.
Người tiêu dùng cũng phải tính đến thông lượng ghi nhật ký cho ví dụ. Mục đích chung là 3 MB / s cho mỗi vCore với tối đa 22MB / s cho phiên bản và Business Critical là 4 MB / s cho mỗi vCore với tối đa 48 MB / s cho toàn bộ phiên bản. Theo kinh nghiệm của tôi khi làm việc với khách hàng, nhiều người đã vượt xa những giới hạn này đối với thông lượng ghi. Đối với một số người, nó là một showstopper, và đối với những người khác, họ có thể tối ưu hóa và sửa đổi hệ thống của mình để giảm tải.
Ngoài việc cần biết thông lượng tổng thể và các yêu cầu I / O, kích thước lưu trữ cũng được gắn với số lượng vCores được chọn. Vì mục đích chung:
4 vCores = 2 TB max
8 - 80 vCores = 8 TB max
Đối với Doanh nghiệp Quan trọng:
4 – 16 vCores = 1 TB
24 vCores = 2 TB
32 - 80 vCores = 4 TB
Đối với Mục đích chung, khi bạn đạt đến 8 vCores, bạn có thể sử dụng tối đa bộ nhớ có sẵn, điều này hoạt động tốt cho những người chỉ cần Mục đích chung. Nhưng khi bạn cần Business Critical, mọi thứ có thể khó khăn hơn. Tôi đã làm việc với nhiều khách hàng có nhiều TB được phân bổ cho các máy ảo với bộ xử lý lôgic 4, 8, 16 và 24. Đối với bất kỳ khách hàng nào trong số này, họ sẽ phải chuyển lên ít nhất 32 vCores chỉ để đáp ứng yêu cầu lưu trữ của họ, một lựa chọn tốn kém. Cơ sở dữ liệu Azure SQL có vấn đề tương tự với kích thước cơ sở dữ liệu tối đa và Microsoft đã đưa ra tùy chọn Hyperscale. Chúng tôi hy vọng điều này sẽ trở thành một tùy chọn cho Phiên bản được quản lý vào một thời điểm nào đó để giải quyết các giới hạn bộ nhớ theo cách tương tự.
Kích thước của tempdb cũng tương quan với số lượng vCores. Trong lớp Mục đích chung, bạn nhận được 24 GB trên mỗi vCore (tối đa 1.920 GB) cho các tệp dữ liệu, với giới hạn kích thước tệp nhật ký tempdb là 120 GB. Đối với bậc Quan trọng dành cho Doanh nghiệp, tempdb có thể phát triển hết cỡ lên đến kích thước lưu trữ phiên bản hiện có sẵn.
OLTP trong bộ nhớ
Đối với những người hiện đang tận dụng OLTP Trong Bộ nhớ (hoặc dự định), hãy lưu ý rằng nó chỉ được hỗ trợ trong cấp dịch vụ Quan trọng dành cho Doanh nghiệp. Dung lượng có sẵn cho các bảng trong Bộ nhớ cũng bị giới hạn bởi vCores:
4 vCores = 3.14 GB
8 vCores = 6.28 GB
16 vCores = 15.77 GB
24 vCores = 25.25 GB
32 vCores = 37.94 GB
40 vCores = 52.23 GB
64 vCores = 99.90 GB
80 vCores = 131.86 GB
Kết luận
Khi lập kế hoạch di chuyển sang Azure SQL Managed Instance, có nhiều cân nhắc cần tính đến trước khi quyết định di chuyển. Trước tiên, bạn cần hiểu đầy đủ các yêu cầu về bộ nhớ, CPU và lưu trữ của mình, vì điều này sẽ xác định kích thước của phiên bản. Điều quan trọng không kém là biết các yêu cầu I / O lưu trữ của bạn là gì. IOPS và thông lượng cho cấp Mục đích chung được liên kết trực tiếp với vCores và kích thước của tệp cơ sở dữ liệu. Đối với Doanh nghiệp quan trọng, nó được gắn với số lượng vCores. Nếu bạn có khối lượng công việc rất nhiều I / O, thì Business Critical là cấp dịch vụ hấp dẫn hơn do nó cung cấp số lượng IOPS và thông lượng cao hơn. Thách thức với Business Critical là dung lượng lưu trữ thấp hơn và chỉ hỗ trợ 1TB cho toàn bộ phiên bản lên đến 16 vCores.
Với việc lập kế hoạch phù hợp và có thể hợp nhất các phiên bản lớn hơn thành các Phiên bản được quản lý nhỏ hơn, việc cung cấp này có thể là một lựa chọn di chuyển rất khả thi cho nhiều tổ chức. Sự hấp dẫn là những lợi ích của việc có các bản sao lưu được quản lý, tích hợp sẵn HA với SLA là 99,99%, các tính năng và tùy chọn bảo mật được bổ sung và không phải lo lắng về việc vá một phiên bản OS hoặc SQL Server.
