Triển khai SharePoint trên Microsoft Azure IaaS v2 – Phần 3

Ở phần 2 tôi đã giới thiệu về các scenario triển khai SharePoint trên Azure. Để hiểu đầy đủ trong loạt bài này đặc biệt từ phần 3 trở đi bạn cần nắm cơ bản các dịch vụ của Azure sẽ được nhắc đến.

Trong phần này chúng ta cùng tìm hiểu về 6 yếu tố chính để xây dựng SharePoint farm trên Azure. Các yếu tố chính mà tôi đề xuất gồm có:

  • Mô hình triển khai
  • Quản lý identity
  • Business continuity
  • Performance và Capacity
  • Bảo trì và vận hành
  • Chi phí

Mô hình triển khai

Để bắt đầu triển khai SharePoint farm trên Azure, bạn cần xác định mô hình bạn dự định triển khai là gì? Mô hình single-server chạy tất cả role trên 1 server, hay mô hình gồm 1 web-front end server, 2 application server, 2 database server … Ở đây tôi sẽ không đề cập lại cách thiết kế, xác định các mô hình farm.

Sau khi đã nắm mô hình farm bạn cần triển khai, bắt đầu xem xét đến các thành phần như hình dưới đây.

  • Regional Virtual Network
  • Resource Group
  • Virtual Network
  • Availability Set
  • Subnet
  • Virtual Machine
  • Site Connectivity
  • Storage
  • Các dịch vụ Azure khác

azure-resource

Regional Virtual Network

Trước đây khi Azure IaaS v2 chưa được Microsoft tung ra, bạn sẽ quen thuộc với khái niệm Affinity Group ở v1. Khi bạn nhóm các resource vào trong cùng 1 Affinity group, các resource sẽ cùng được nằm trong một khu vực (có thể khác datacenter). Ở phiên bản Azure IaaS thì khái niệm Affinity Group không còn được sử dụng nữa và Microsoft khuyên dùng Regional Virtual Network. Việc nhóm các resource trong cùng 1 Regional Virtual Network để đảm bảo performance được tối ưu hóa, cũng như giúp bạn quản lý dễ dàng hơn.

Resource Group cũng là 1 khái niệm mới trên Azure IaaS v2. Trước đây là Azure Cloud Service. Resource Group được sử dụng để nhóm các resource lại với nhau nhằm giúp bạn dễ quản lý hơn. Bạn cần phải tạo 1 resource group trước khi có thể tạo virtual network hoặc virtual machine. Một trong những ưu điểm của Azure Resource Group là cho phép bạn có thể đơn giản việc xây dựng các template chuẩn và triển khai các template này.

resource-group

Chú ý là bạn đừng nhầm lẫn Azure Resource Group và Regional Virtual Network nhé. Azure Resource Group là để bạn nhóm các resource và 1 nhóm để dễ quản lý hơn. Với Regional Virtual Network, khi bạn đặt tất cả thành phần Azure vào kể cả các resource, các thành phần này sẽ kết nối với nhau nhanh hơn vì trong cùng một region/datacenter, làm giảm đi latency.

Virtual Network

Để có thể thiết kế được sơ đồ network trên Azure, bạn cần xác định bạn dự định triển khai mọi thứ trên Azure kể cả SharePoint và Active Directory hay chỉ triển khai SharePoint farm trên Azure và Active Directory vẫn ở hạ tầng on-premises. Nếu bạn kết nối với On-premises bạn cần phải thiết lập Azure site-to-site VPN.

Một điểm lưu ý khi thiết kế network là việc sử dụng các reserved IP để quản lý IP address, tránh trường hợp khi các máy ảo khởi động lại làm thay đổi IP address (đặc biệt là domain controller và DNS server role của bạn).

Nếu yêu cầu về bảo mật ở tầng network, bạn cần chia lại subnet và thiết lập DMZ trên Azure. Các bài viết trong tương lai (ngoài loạt bài này) tôi sẽ chia sẻ về việc bảo mật trên Azure.

Virtual Machine

Tất nhiên là virtual machine (máy ảo) là thứ không thể thiếu cho SharePoint farm. Azure cung cấp cho bạn 4 loại máy ảo, gồm A-series, D-series, DS-series và G-series. Mỗi loại này sẽ có thông số cấu hình khác nhau, số lượng tối đa data disk và IOPS mà máy ảo loại đó hỗ trợ.

Nếu bạn cần sử dụng Azure Premium Storage, bạn chú ý là chỉ có DS, DSv2 và GS-series là được hỗ trợ.

Một trong những điểm cần chú ý là bạn nên mở rộng máy ảo (scale out) thay vì sử dụng 1 máy ảo có cấu hình thật tốt cho SharePoint farm của bạn. Nói cách khác là bạn nên có 2-3 máy ảo có cấu hình thấp thì tốt hơn là có 1 máy ảo cấu hình cao. Có 2 lý do chính để giải thích:

  1. Chi phí của mô hình có 2-3 máy ảo cấu hình thấp sẽ thấp hơn chi phí của mô hình có cấu hình cao.
  2. Khi bạn muốn giảm thông số, bạn phải tắt cả máy ảo đó (với cấu hình cao) thay vì chỉ cần tắt đi 1 trong 3 máy ảo (với cấu hình thấp). Giải thích bằng tiếng Việt có thể sẽ làm bạn khó hiểu, nên bạn có thể nghĩa là Scale-out is better than Scale-up (2 thuật ngữ này sẽ dễ hiểu hơn).

Chắc chắn là scale-out sẽ làm bạn tốn thêm thời gian, effort để quản lý rồi.

Storage

Có 2 loại Storage account trên Azure: Standard và Premium. Loại Standard chỉ hỗ trợ tối đa 20,000 IOPS. Mỗi disk hỗ trợ tối đa 500 IOPS. Nếu bạn muốn tăng performance bạn nên chọn Premium Storage vì ổ cứng sử dụng đều là SSD với tốc độ rất nhanh.

Vì mỗi disk chỉ hỗ trợ 500 IOPS, bạn có thể sử dụng phương pháp ghép (thuật ngữ gọi là disk stripping) để tăng thêm IOPS. Ví dụ tôi ghép 2 disk lại sẽ được 1000 IOPS. Azure hoàn toàn hỗ trợ bạn về disk stripping.

Với SharePoint farm của bạn có nhiều content database bạn cần tính toán các máy ảo cũng như storage cho hợp lý. 1 content database cần khoản 0.2 – 0.5 IOPS/GB. Ví dụ bạn có tổng là 1000 GB bạn cần 200 – 500 IOPS (tất nhiên trong trường hợp bạn chia thành 5 content database).

Khi tạo storage account, bạn nên đặt chung với region/datacenter của máy ảo. Tất nhiên nếu bạn đưa hết vào trong cùng 1 resource group thì không phải lo.

Một trong những tip khi làm việc với SQL Server và storage là việc bạn sử dụng SQL file group ở đồng thời nhiều disk.

Cuối cùng là bạn không nên lưu trữ data ở ổ D vì đây là ổ tạm (temporary disk).

Tôi hay tư vấn cho các khách hàng theo bảng dưới đây. Các máy ảo chạy web front-end role tôi chọn máy ảo có size là A5, số lượng CPU là 2, 14 GB RAM, tổng số lượng disk là 4 và tối đa 2000 IOPS. Lý do vì web front-end role thường không xử lý nhiều về code logic (nếu design đúng theo 3 tier cũng như pattern của bạn rõ ràng). Ở các máy ảo chạy application role (chủ yếu tôi thấy là Search hoặc 1 custom service application nào đó) cần máy trâu hơn một tí, tôi chọn A6 với 4 CPU core, 28 GB RAM, hỗ trợ 4000 IOPS.

Trong trường hợp SharePoint farm của bạn quá lớn đòi hỏi có các máy ảo chạy Search riêng, bạn cũng có thể sử dụng A6, hoặc A4 với 16 disk. Tại sao tôi chọn loại size có nhiều disk như vậy. Hãy tưởng tượng hệ thống Search của bạn đồ sộ thì index file của bạn cũng không nhỏ. Với 16 disk sẽ giúp bạn có nhiều dung lượng hơn để lưu trữ index file.

Tùy vào yêu cầu performance hoặc SharePoint farm của bạn chạy nhiều ứng dụng quan trọng (người ta hay gọi business-critical application) bạn sẽ có sự lựa chọn về loại size phù hợp. Ví dụ size DS4 có thể gắn với Premium storage và hỗ trợ IOPS lên đến 25,600.

vm-plan

Phần tiếp theo tôi sẽ chia sẻ về Identity Management, tập trung chủ yếu vào việc lên kế hoạch cho identity của SharePoint farm trên Azure.

Thuan Soldier

Anh Nguyễn Ngọc Thuận là chuyên gia công nghệ về các giải pháp Microsoft Cloud Productivity, hiện đang làm việc tại FPT Software. Anh có 8 năm kinh nghiệm làm việc với các sản phẩm của Microsoft cho các khách hàng Mỹ và Singapore, trong đó 2 năm làm việc cho các tổ chức chính phủ Singapore. Với những cống hiến cho cộng đồng và các khách hàng của Microsoft, anh Thuận được danh hiệu Microsoft Most Valuable Professional (MVP) 6 lần liên tiếp từ 2011 – 2016. Đến với AzureVN.NET, Thuận mong muốn được chia sẻ kinh nghiệm về Azure IaaS (Infrastructure-As-A-Service) và Azure Security.

thuansoldier has 36 posts and counting.See all posts by thuansoldier

Trả lời

Thư điện tử của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *