Mở khóa Azure: Cách xây dựng cơ sở hạ tầng cơ sở dữ liệu SQL có tính linh hoạt cao

Không có gì bí mật khi trong những năm gần đây Cơ sở hạ tầng dưới dạng Dịch vụ và Nền tảng dưới dạng Dịch vụ ngày càng trở nên phổ biến trong các dự án khác nhau do khả năng của chúng, đặc biệt là tính hiệu quả và tính linh hoạt của tài nguyên. Kết quả là Microsoft đã dành rất nhiều thời gian và công sức để tạo ra một môi trường thân thiện với người dùng trong đó SQL có thể được sử dụng.

Nhóm Social Discovery Group sử dụng nhiều loại cơ sở dữ liệu bao gồm SQL để hỗ trợ các sản phẩm của chúng tôi. Với danh mục gồm hơn 40 dịch vụ toàn cầu giúp gặp gỡ và kết nối trên toàn thế giới, cơ sở người dùng của chúng tôi bao gồm hơn 250 triệu người trên toàn cầu. Để đảm bảo độ tin cậy của sản phẩm cho người dùng, chúng tôi lưu giữ một phần cơ sở hạ tầng quan trọng trên đám mây. Điều này giúp tăng cường khả năng phục hồi, bảo mật và tính linh hoạt của nó.

Chúng tôi khá có kinh nghiệm trong việc triển khai cơ sở dữ liệu máy chủ và dịch vụ trên nhiều nền tảng khác nhau, bao gồm cả cụm Kubernetes. Tuy nhiên, chúng tôi phải đối mặt với nhu cầu làm cho một phần cơ sở hạ tầng cơ sở dữ liệu SQL có liên quan trong đám mây Azure trở nên linh hoạt, hiệu quả và đáng tin cậy nhất có thể. Có 3 cách để sử dụng SQL trong đám mây Microsoft Azure:

• Cơ sở dữ liệu Azure SQL
• Phiên bản được quản lý Azure SQL
• Máy chủ SQL trên máy ảo Azure

Sau khi nghiên cứu, chúng tôi đã quyết định sử dụng cơ sở dữ liệu Azure SQL. Để làm rõ cho những người chưa bao giờ nghe đến cái gọi là cơ sở dữ liệu Azure SQL, chúng là cơ sở dữ liệu đám mây được quản lý được cung cấp như một phần của Microsoft Azure.

Tôi đã nhấn mạnh những lợi ích sau:

• Không cần phải lo lắng về các bản cập nhật hoặc hỗ trợ cuối đời;
• Dễ dàng cấu hình và triển khai;
• Tốc độ triển khai (và do đó phát triển) và khả năng mở rộng;
• Tính sẵn sàng cao;
• Khả năng chịu lỗi;
• Dễ dàng sao lưu;
• Tối ưu hóa chi phí;
• Một hệ thống giám sát Microsoft Azure tích hợp.

Bây giờ chúng ta hãy nói từng bước một và xem quá trình triển khai và tạo cơ sở dữ liệu. Điều này có thể được thực hiện bằng cách sử dụng tập lệnh Power Shell hoặc Azure CLI, nhưng để rõ ràng hơn, tôi xem xét quy trình bằng giao diện đồ họa của cổng thông tin. Để thực hiện việc này, hãy truy cập Azure SQL, nhấp vào 'Tạo' và chọn 'Cơ sở dữ liệu SQL'.

Chúng tôi chỉ định nhóm tài nguyên, chọn xem có máy chủ hiện có hay tạo một máy chủ mới (cho biết tên và dữ liệu của quản trị viên) và đặt tên cho cơ sở dữ liệu. Tôi khuyên bạn nên chọn các gói dựa trên DTU (đơn vị giao dịch cơ sở dữ liệu) với sự kết hợp cân bằng giữa tài nguyên điện toán và lưu trữ cho khối lượng công việc chung của chúng ta.

Ngoài ra còn có một số tab dành cho cài đặt: Mạng, Bảo mật, Cài đặt bổ sung và Thẻ; đối với cấu hình tiêu chuẩn tối thiểu, những cấu hình này có thể được giữ nguyên theo mặc định. Sau đó chúng ta chờ cơ sở dữ liệu được tạo. Điều này hoàn thành việc thiết lập tối thiểu và cơ sở đã hoàn tất.

Kích thước của tài nguyên cơ sở dữ liệu có thể được thay đổi cực kỳ dễ dàng, theo đúng nghĩa đen chỉ bằng một cú nhấp chuột và trong trường hợp không đủ tài nguyên, chúng ta có thể đặt các tham số cần thiết về kích thước và hiệu suất.

Sau đó, bạn có thể kết nối với cơ sở dữ liệu của mình theo bất kỳ cách nào bạn muốn từ bên ngoài mà không quên thêm địa chỉ IP hoặc mạng con hoặc cho phép tất cả các kết nối trong tường lửa của máy chủ nơi cơ sở dữ liệu này được lưu trữ.

Thật thuận tiện khi kết nối và quản lý thêm thông qua SQL Server Management Studio (SSMS), nhưng cũng có thể thực hiện điều đó thông qua các công cụ khác và chính cổng Azure.

Ngoài điểm kết nối công cộng, bạn cũng có thể tạo điểm kết nối riêng bằng cách thêm máy chủ vào mạng con được yêu cầu và định cấu hình vùng DNS riêng.

Nói về khả năng chịu lỗi, ở đây chúng ta thấy cách triển khai chuyển đổi dự phòng rất thuận tiện và trực quan, một nhóm máy chủ bảo vệ có trụ sở tại các khu vực khác nhau.

Trong Azure, có thể thêm và xóa cơ sở dữ liệu trên các máy chủ trong nhóm chuyển đổi dự phòng, chuyển đổi dự phòng bắt buộc và chế độ chuyển đổi dự phòng tự động.

Bạn có thể thấy điều này trong ảnh chụp màn hình bên dưới. Hãy đặt tên cho nhóm chuyển đổi dự phòng và đưa máy chủ vào trạng thái chuyển đổi dự phòng. Đồng bộ hóa cơ sở dữ liệu được chỉ định sẽ tự động bắt đầu. Máy chủ thứ hai sẽ ở chế độ chỉ đọc. Trong trường hợp xảy ra lỗi, lưu lượng truy cập sẽ tự động được chuyển sang khu vực thứ hai và máy chủ chính và phụ sẽ tự động chuyển đổi địa điểm.

Nhưng chuyển đổi dự phòng sẽ không giúp ích gì nếu có vấn đề ở cấp độ dữ liệu trong cơ sở dữ liệu. Để chắc chắn trong trường hợp này, bạn cần tạo bản sao lưu. Có thể định cấu hình các bản sao lưu cả trong cổng thông tin và thông qua các công cụ của bên thứ ba hoặc, ví dụ: Azure DevOps (trong quy trình, bạn có thể sử dụng tác vụ SqlAzureDacpacDeployment + AzureFileCopy). Trong cổng thông tin, các bản sao lưu được định cấu hình trên tab Sao lưu và các chính sách lưu trữ cần thiết được đặt.

Nếu bạn muốn sử dụng các công cụ sao lưu của bên thứ ba, tôi khuyên bạn nên xem xét các công cụ gói Azure DevOps hoặc SQL.

Theo tôi, quá trình khôi phục trên cổng thông tin không thuận tiện lắm. Điều đầu tiên bạn nhận thấy là thời gian phục hồi lâu đối với cơ sở dữ liệu thử nghiệm đơn giản. Ví dụ: tôi phải mất hơn nửa giờ để khôi phục cơ sở dữ liệu kích thước cơ bản 30 MB từ bản sao lưu ngày hôm qua! Sau khi liên hệ với bộ phận hỗ trợ của Microsoft Azure, tôi được khuyên nên sử dụng tập lệnh PowerShell để khôi phục và được thông báo rằng kích thước cơ sở dữ liệu ít nhất phải là S3 cho quá trình khôi phục và sau đó kích thước có thể giảm xuống. Dưới đây tôi sẽ trình bày một số kịch bản và sự phát triển của mình về chủ đề này, chúng có thể được cải thiện và nâng cao nhưng tôi chắc chắn rằng nhiều bạn có thể thấy chúng hữu ích.

Tôi sẽ hướng dẫn bạn từng bước:

1. Trong trường hợp bạn chưa cài đặt PowerShell ISE trên Windows, hãy tải xuống tại đây: https://github.com/PowerShell/Pohell/releases/download/v7.3.0/PowerShell-7.3.0-win-x64.msi
   https://github.com/PowerShell/PowerShell/releases/download/v7.3.0/PowerShell-7.3.0-win-x86.msi
2. Tiếp theo, bạn cần cài đặt mô-đun Azure: Install-Module Az
3. Sau khi cài đặt mô-đun AZ, hãy nhập mô-đun AZ: Import-Module Az
4. Sau khi nhập, bạn có thể kết nối với tài khoản Azure của mình: Connect-AzAccount. Một cửa sổ bật lên sẽ xuất hiện để đăng nhập vào tài khoản Azure của bạn, sau đó bạn sẽ được kết nối
5. Chạy tập lệnh PowerShell.

 “ #Variables in use $Database = Get-AzSqlDatabase -ResourceGroupName "Test" -ServerName "test-serv1" -DatabaseName "dbforscript" $TargetDB = "dbforscript_new" $PITRtimedate = "2022-12-02 10:00:00Z" ##вам нужно увидеть действительную дату и время на портале $PITRSLO = "S3" $PITRNEWSLO = "S0" $PITRedition = "Standard" $failoverGroupRG = "Test" $failoverGroupS = "test-serv1" $failoverGroupDB = "dbforscript" $removedbfromfgRG = "Test" $removedbfromfgS = "test-serv1" $removedbfromfgDB = "XXXXX" $dropreplicaRG = "Test" $dropreplicaS = "test-serv2" $dropreplicaDB = "dbforscript" $sourcedbRG = "Test" $sourcedbS = "test-serv1" $sourcedbDBname = "dbforscript" $sourcedbDBNEWname = "dbforscript_old" $TargetDBNEWname = "dbforscript" “

1 - Mã này bắt đầu khôi phục cơ sở dữ liệu bằng một tên khác. Nếu tên gốc của cơ sở dữ liệu đang được khôi phục là "dbforscript", thì tên của cơ sở dữ liệu được khôi phục sẽ là dbforscript_new. Cơ sở dữ liệu được khôi phục sẽ là phiên bản SLO S3 trở lên, đây là cách được khuyến nghị để thực hiện hành động này, biến cho điều này là $PITRSLO = "S3", bạn có thể sử dụng S3 hoặc cao hơn. Sau đó, chúng tôi sẽ đặt lại mức SLO về mức ban đầu, mức này chỉ dành cho quá trình khôi phục.

 “Restore-AzSqlDatabase -FromPointInTimeBackup -PointInTime $PITRtimedate -ResourceGroupName $Database.ResourceGroupName -ServerName $Database.ServerName -TargetDatabaseName $TargetDB -ResourceId $Database.ResourceID -Edition $PITRedition -ServiceObjectiveName $PITRSLO”

2 - Mã này sẽ xóa cơ sở dữ liệu nguồn khỏi nhóm chuyển đổi dự phòng: cơ sở dữ liệu nguồn: dbforscript.

 “$failoverGroup = Get-AzSqlDatabase -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -DatabaseName $failoverGroupdb | Remove-AzSqlDatabaseFromFailoverGroup -ResourceGroupName $removedbfromfgRG -ServerName $removedbfromfgS -FailoverGroupName $removedbfromfgDB”

3 - Mã này sẽ xóa cơ sở dữ liệu bản sao khỏi máy chủ nơi nó được đặt: dbforscript trên máy chủ test-serv2.

 “Remove-AzSqlDatabase -ResourceGroupName $dropreplicaRG -ServerName $dropreplicaS -DatabaseName $dropreplicaDB”

4 - Mã này sẽ đổi tên cơ sở dữ liệu gốc thành một tên khác: sau khi đổi tên, dbforscript sẽ là dbforscript_old.

 “Set-AzSqlDatabase -ResourceGroupName $sourcedbRG -DatabaseName $sourcedbDBname -ServerName $sourcedbS -NewName $sourcedbDBNEWname”

5 - Mã này sẽ đổi tên cơ sở dữ liệu đã khôi phục thành tên cơ sở dữ liệu ban đầu, đổi tên dbforscript_new thành dbforscript.

 “Set-AzSqlDatabase -ResourceGroupName $Database.ResourceGroupName -DatabaseName $TargetDB -ServerName $Database.ServerName -NewName $TargetDBNEWname”

6 - Mã này sẽ trả mức SLO cơ sở dữ liệu của bạn về giá trị S0 (ban đầu) trước đó. nếu cơ sở dữ liệu của bạn là cơ bản, vui lòng nâng cấp từ S0 lên cơ bản sau trong cổng thông tin.

 “Set-AzSqlDatabase -ResourceGroupName $Database.ResourceGroupName -DatabaseName $TargetDBNEWname -ServerName $Database.ServerName -Edition $PITRedition -RequestedServiceObjectiveName $PITRNEWSLO -MaxSizeBytes 10737418240”

7 - Mã cuối cùng thêm cơ sở dữ liệu đã khôi phục vào nhóm chuyển đổi dự phòng đã có tên gốc (vì chúng tôi đã thay đổi nó trong mã trước đó).

 “$failoverGroup = Get-AzSqlDatabase -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -DatabaseName $TargetDBNEWname | Add-AzSqlDatabaseToFailoverGroup -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -FailoverGroupName $removedbfromfgDB”

Bạn có thể xem xét thêm tham số - ErrorAction Stop sau lệnh. Điều này sẽ ngăn các lệnh sau được thực thi trong trường hợp có lỗi và sẽ không có hiện tượng lăn cầu tuyết.

Ngoài ra, bạn có thể thêm Get-Date vào đầu và cuối tập lệnh để tính thời gian thực hiện. Trong trường hợp của tôi, cơ sở dữ liệu khoảng 3,3 GB đã được khôi phục bằng tập lệnh như vậy trong vòng chưa đầy 6 phút.

Nếu muốn, bạn chắc chắn có thể tối ưu hóa tập lệnh, thêm nó thông qua Azure DevOps, giảm số lượng biến hoặc mã hóa cứng thứ gì đó, nhưng tôi đã cố gắng mô tả nó càng chi tiết càng tốt và theo cách mà mọi người đều có thể hiểu được.

Giám sát cơ sở dữ liệu trên Azure và khả năng tích hợp với nhiều hệ thống khác nhau, chẳng hạn như Datadog, đáng được quan tâm đặc biệt. Việc giám sát khá thuận tiện, nhưng không phải là không có sắc thái (ví dụ: tại thời điểm viết bài, người dùng chỉ đọc chỉ có thể xem giám sát cho một cơ sở dữ liệu chứ không phải tất cả cùng một lúc... đây là các sắc thái).

Tóm lại, nhóm của chúng tôi đã tối ưu hóa thành công chi phí đồng thời giải quyết các mối lo ngại liên quan đến cập nhật và ngừng hỗ trợ. Chúng tôi đã đạt được những cải tiến về hiệu suất, khả năng phục hồi, tốc độ phát triển và tính linh hoạt. Ngoài ra, việc triển khai tập lệnh đã nâng cao đáng kể khả năng phục hồi nhanh chóng của chúng tôi khi cần.

Viết bởi Pavel Shapurau, Kỹ sư trưởng DevOps tại Social Discovery Group.