Powered by Blogger.

Hoạch định kiến trúc “Vật lý” và “Luận lý” triển khai SharePoint theo mô hình Farm

Hoạch định và triển khai SharePoint mô hình Farm không phải là một nhiệm vụ đơn giản. SharePoint hiếm khi được cài đặt trong một môi trường bị cô lập, và thường nó can thiệp vào cơ sở hạ tầng hiện có và chiến lược của công ty. Nhiều yếu tố có thể ảnh hưởng đến thiết kế Farm, hiệu suất, khả năng mở rộng và dự phòng - từ các thiết bị phần cứng trong mạng lưới tổ chức, cho đến mô hình mạng. Kết quả là, tận dụng và tìm kiếm sự thỏa hiệp trong số những yếu tố giúp xây dựng môi trường phù hợp, đáng tin cậy và linh hoạt hơn.

Trong bài này, bạn sẽ thấy các cấu hình khuyến nghị, bất chấp việc ứng dụng SharePoint vào các lĩnh vực khác nhau. Mọi thông tin được trình bày gồm tập hợp các khuyến nghị về các hành động khác nhau bạn cần phải thực hiện hoặc phải lưu thêm khi bạn cài đặt và cấu hình SharePoint trong môi trường của bạn. Chúng tôi đã cố gắng để tất cả các phần cấu trúc theo dòng chảy tự nhiên của quá trình cài đặt SharePoint từ đầu - từ việc phân tích các yêu cầu trước khi cài đặt cho đến các hành động hậu triển khai.
Giới thiệu

Khi triển khai SharePoint, các tổ chức sẽ đối mặt với hàng loạt các tác vụ – từ hoạch định, chiến lược, thiết kế kiến trúc và hạ tầng, thiết kế giao diện, di trú cho đến phát triển. Tất cả các tác vụ này bao hàm định hướng cơ sở hạ tầng linh hoạt, trước khi bắt đầu công việc thực tế. Tuy nhiên, trong thực tế chúng ta phải đối mặt với môi trường lỗi thời và các Farm triển khai không chuẩn sẽ không sẵn sàng để thực hiện các yêu cầu mới. Trong trường hợp này, kiến trúc định hướng sẽ trở thành nền tảng vững chắc cho tất cả các dự án SharePoint.

Tại sao chúng ta quan tâm về hạ tầng mà không phải các vấn đề khác, chẳng hạn như việc phát triển? Khắc phục các lỗi về hạ tầng là công việc tốn kém và dẫn đến các thay đổi quan trọng trong SharePoint farm. Ví dụ, Index Role bị gán sai vào server và cấu hình Search không đúng có thể dẫn đến hiệu suất và khả năng dự phòng gặp vấn đề và việc khắc phục nó phải mất đến ba ngày. Các lỗi phát sinh khi phát triển thì dễ dàng khắc phục và ít tốn kém hơn, nhưng đôi lúc những lỗi như vậy có thể trở thành các lỗi về cơ sở hạ tầng dẫn đến việc thay đổi trong thiết kế hạ tầng.


“Hoạch định về kiến trúc”


Chúng ta sẽ hoạch định mô hình farm và các liên kết mạng trước khi bắt đầu cài đặt. Việc đầu tiên là bắt đầu thiết kế kiến trúc SharePoint trong hệ thống mạng của bạn. Điều này yêu cầu bạn phải hiểu biết về cấu trúc hệ thống mạng, kiểm tra các thiết bị mạng và chọn mô hình SharePoint phù hợp với hạ tầng hiện tại và có thể mở rộng trong tương lai.

Kiểm tra hệ thống mạng 

Hãy bắt đầu bằng việc mô tả lại thiết kế mạng hiện tại, vị trí các ứng dụng và hệ thống các máy chủ. Bạn có thể sử dụng Microsoft Visio và mẫu “Network Diagram” để mô phỏng lại toàn bộ hệ thống.

Ghi lại toàn bộ thông tin về vị trí của các máy chủ trong hệ thống, như Domain Controller, File Server, Mail Server, và các máy chủ khác. Và đừng quên thông tin về các dịch vụ mạng – firewall, proxy,… Ví dụ, vị trí của các máy chù firewall ISA – địa chỉ IP, danh sách các port được mở và tài khoản quản trị.

Cách tốt nhất để duy trì tài liệu về “Network Diagram” là hãy cập nhật một sơ đồ bao quát toàn bộ các miền và cách thức chúng liên kết với. Hãy xem hình minh họa bên dưới.


Sơ đồ này sẽ cung cấp cho bạn một cái nhìn toàn diện về mô hình hiện có và đảm bảo truy cập nhanh các thông tin trên các miền khác nhau.

Kiểm tra các thiết bị mạng

Tất cả các thiết bị mạng trong một mô hình đóng một vai trò quan trọng, ảnh hưởng đến cách thức mà SharePoint thực thi và tương tác giữa các máy chủ khác nhau. Thông tin về vị trí và các thiết lập của tất cả các bộ Router, Switch, Accelerator trở nên rất quan trọng trong quy hoạch vị trí máy chủ. Ví dụ, vị trí khác nhau của mạng WAN và XML Accelerator trên toàn hệ thống mạng sẽ ảnh hưởng đến việc tổ chức và cấu hình máy chủ SharePoint.

Sự hiện diện của các thiết bị mạng khác nhau ảnh hưởng đến băng thông kết nối và độ trễ giữa các máy chủ của Farm, và do đó, ảnh hưởng đến sự lựa chọn mô hình SharePoint Farm cho thích hợp. Các thiết bị cân bằng tải (NLB), Router và Switch sẽ ảnh hưởng đến tốc độ phản hồi của mạng, do đó Farm cần được thiết kế sao cho ít bị tác động của các thiết bị này.

Hãy tham khảo thêm các liên kết bên dưới để có thông tin chi tiết về gia tốc mạng WAN, cân bằng tải và các thiết bị khác thông qua các SharePoint Farm:


Quản trị viên là người bạn

Các quản trị viên CNTT là người nên tham gia vào việc cấu hình farm từ đầu. Người này sẽ chịu trách nhiệm cho vịêc cấu hình tất cả các máy chủ và các thiết bị trên mạng công ty.

Hầu hết các mô hình SharePoint Farm xuyên qua các miền, chúng ta phải chỉ định các giao thức và mở các port ngay từ đầu. Cách tốt nhất để duy trì hệ thống là phải có một văn bản riêng, chia sẻ với quản trị viên, bảng mô tả về các giao thức và cổng để mở thông qua các dịch vụ mạng.

Thông tin chi tiết về các tài khoản hệ thống và danh sách các port cần mở được mô tả chi tiết trong các bài sau:

Hoạch định tài khoản quản trị và dịch vụ (MOSS) http://technet.microsoft.com/en-us/library/cc263445.aspx
Các yêu cầu về an toàn cho tài khoản của MOSS http://go.microsoft.com/fwlink/?LinkID=92883&clcid=0×409

Đo lường độ trễ của mạng 

Thời gian đáp ứng mạng là một trong những yếu tố quan trọng có thể ảnh hưởng đến thiết kế SharePoint Farm. Lý tưởng nhất, bạn cần để đo độ trễ giữa các máy chủ SharePoint và người sử dụng để tổ chức lại các máy chủ theo thời gian phản hồi nhỏ nhất.

Độ trễ mạng là điểm then chốt để xác định các kịch bản được đề xuất để thực hiện trong việc triển khai SharePoint hiện hành. (Độ trễ - là thời gian cần thiết cho một gói tin đi từ một điểm trên mạng đến một điểm khác).

Sử dụng công cụ Ping để đo lường độ trễ cho:

các người dùng – từ một máy trạm đến một máy chủ Web trên farm;
cho trung tâm tích hợp dữ liệu, nơi đặt các máy chủ của cùng một farm – từ một máy chủ Web ở một trung tâm tích hợp dữ liệu ở xa đến một máy chủ cơ sở dữ liệu đặt ở trung tâm chính.

Đừng quên chia kết quả cho hai, bởi vì tất cả các đo lường chỉ là một chiều, không khứ hồi.

So sánh kết quả với dữ liệu dưới đây, và môi trường bạn triển khai phải có độ trễ thấp hơn các giá trị đó.

Số người dùng Số người dùng đồng thời (10%) Giải pháp tập trung Giải pháp phân tán
100 – 5,000 10 – 500 Băng thông: 3+ Mbps (dual T1)
Độ trễ: < 100 ms Băng thông: 1.5 Mbps (T1)
Độ trễ: <100 ms
10,000 1,000 Băng thông: 3+ Mbps (dual T1)
Độ trễ: <250 ms Băng thông: 1.5 Mbps (T1)
Độ trễ: <500 ms
100,000 10,000 Băng thông: 3+ Mbps (dual T1)
Độ trễ: < 250 ms Băng thông: 1.5 Mbps (T1)
Độ trễ: <500 ms

Băng thông quan trọng cho bất kỳ SharePoint farm nào là 1,5 Mbps (T1) với độ trễ 500ms. Vượt quá các giá trị này sẽ làm tăng thời gian tải trang đáng kể, ít nhất 4 lần. Hãy tham khảo các biểu đồ trong tài liệu về “Hoạch định cho yêu cầu băng thông", để biết chi tiết thêm về băng thông và kết quả độ trễ trong điều kiện khác nhau.

Băng thông mạng và độ trễ hiện hữu ảnh hưởng đáng kể đến triển khai theo địa lý. Chuyển dữ liệu qua các liên kết WAN trải qua nhiều thành phố, tiểu bang, tỉnh, quốc gia, hay lục địa đòi hỏi đường thực sự nhanh chóng để cung cấp thời gian đáp ứng đầy đủ, do đó việc thiết kế các mô hình phải triệt để.


Hiểu rõ cách liên lạc của SharePoint farm

Trước khi thảo luận về máy chủ dự phòng và các mô hình farm, chúng ta xem xét lại các máy chủ farm và cách chúng giao tiếp với nhau. Những hình ảnh sau đây từ bài "Hoạch định môi trường Extranet cho MOSS” trên trang TechNet minh họa các kênh truyền thông trong một farm máy chủ và máy chủ xử lý yêu cầu của người dùng cuối.


Khi người sử dụng đưa ra một truy vấn, truy vấn được gửi đến một máy chủ Web. Các máy chủ Web giao tiếp với máy chủ truy vấn để tạo ra một danh sách kết quả, và sau đó liên lạc với các máy tính đang chạy Microsoft SQL Server để mở rộng danh sách kết quả với các văn bản tổng kết, URL, và điều chỉnh theo chính sách an ninh. Song song, máy chủ Web sẽ lấy trang dữ liệu từ SQL Server và chuyển hoá lại cho người dùng. Sơ đồ này sẽ chúng ta hiểu rõ vai trò nào được dùng trên các máy chủ farm.

Hoạch định mô hình cơ sở

Phân tích cơ sở hạ tầng hiện có và hoạch định một mô hình SharePoint cho Redundancy. Thuật ngữ redundandcy thường được diễn giải sai đồng nghĩa với tính sẵn sàng - Availability.

Redundancy đề cập đến việc sử dụng nhiều máy chủ trong một môi trường cân bằng tải cho một vài mục đích, như để cải thiện hiệu suất farm, mở rộng quy mô để tăng lượng người dùng khác, và để cải thiện tính sẵn sàng.
Availability là một khái niệm chuyên biệt hơn, đề cập đến một môi trường nhiều máy chủ được thiết kế để chấp nhận các kết nối và hoạt động bình thường ngay cả khi một hoặc nhiều máy chủ trong các farm không hoạt động. Do đó, Availability bao hàm luôn cả Redundancy.

Có một vài mô hình khác nhau - từ ba đến sáu máy chủ trong một farm, có thể được sử dụng như là một mô hình cơ sở. Sự lựa chọn phụ thuộc vào mức độ Redyndancy và phần cứng sẵn có. Không phải tất cả các khách hàng có thể đủ khả năng áp dụng mô hình với sáu hoặc mười máy chủ trong farm do hạn chế khả năng ngân sách hoặc do khả năng của trung tâm dữ liệu. Tìm kiếm sự thỏa hiệp giữa số lượng các máy chủ, kiểu hosting và vai trò của các máy chủ trở thành nhiệm vụ quan trọng, bởi vì sự lựa chọn này sẽ ảnh hưởng đến hiệu suất và khả năng mở rộng của các SharePoint farm trong vài năm tới.


Mô hình Farm với ba máy chủ 
Tính sẵn có tối thiểu cho một farm có thể bắt đầu với vài máy chủ, chúng ta có mô hình "3-servers farm". Trong mô hình này, vai trò Web và Application được đặt cùng với nhau trên một nhóm và vai trò cơ sở dữ liệu là nhóm khác. Khi đó, chúng ta sẽ có hai lựa chọn: Redundant cho nhóm Web, hay redundant cho nhóm cơ sở dữ liệu – các bạn xem hình minh họa bên dưới.



Một farm với hai máy chủ Web cung cấp khả năng redundant cho vai trò Web và Application, nâng cao hiệu suất tổng thể. Một nhược điểm của thiết kế này là dữ liệu của bạn không được redundant (mô hình bên trái). Trong trường hợp khác, một farm với hai máy chủ cơ sở dữ liệu (cluster) cung cấp khả năng redundant cho dữ liệu, tăng tính sẵn sàng của dữ liệu quan trọng, nhưng người dùng có thể bị tạm dán đoạn truy cập, khi máy chủ Web Server bị sự cố (mô hình bên phải).

Mô hình "3-ervers farm" buộc chúng ta phải lựa chọn giữa khả năng dự phòng và hiệu suất. Giới hạn này là do hạn chế về số lượng các máy chủ không thể cung cấp khả năng dự phòng và hiệu suất cao cùng một lúc.

Khả năng Redundancy có thể đạt được bằng cách đặt các Query Role trên cả hai máy chủ Web App. Trong trường hợp này, máy chủ cơ sở dữ liệu là nơi duy nhất cho Index Role, nhưng điều này sẽ cản trở hiệu suất tổng thể. Index Role tiêu thụ rất nhiều tài nguyên CPU và HDD, đó là lý do tại sao các máy chủ cơ sở dữ liệu không phải là nơi tối ưu nơi dành cho vai trò này. Giải pháp thay thế là phân công Index Role vào máy chủ Web cùng với Query Role, nhưng điều này dẫn đến hê thống không hoạt động hiệu quả, bởi vì trong trường hợp này, Index sẽ không được tuyên truyền đến một Query Server trong farm.

Nếu hiệu suất là một trong những ưu tiên, sau đó mới xem xét việc sử dụng Query Server và Index Server Roles trên máy chủ ứng dụng web khác nhau. Thì thiết kế này linh hoạt theo nghĩa khả năng mở rộng, bởi vì với các máy chủ mới trong farm thay đổi vai trò của các máy chủ Index và Query là không cần thiết.

Thật thú vị, một bài báo trên TechNet (http://is.gd/8QbS, trang 26) giải thích rằng một Query Server không thể được sử dụng với các máy chủ Web Application cho mô hình “3-servers farm”. Thực tế, Web App và Query Role đi cùng nhau vô cùng phổ biến, các trường chúng không ḍi cùng nhau (một trong những lý do là Query Server không sử dụng cân bằng tải- nó sử dụng thuật toán riêng của mình). Những điều thực sự có nghĩa là trong bài viết trên TechNet là đặt Index trên máy chủ cơ sở dữ liệu là một giải pháp không được đề nghị cho tất cả các tình huống.

Mô hình bốn máy chủ trong một farm - Four Servers Farm

Bổ sung thêm máy chủ thứ tư để tăng thêm khả năng Redundant cho máy chủ Database hoặc Web Server. Tuy nhiên, nó không giúp nhiều cho hiệu suất. Hiện tại mô hình này cũng bị cùng nhược điểm với mô hình “3-servers farm" - không có chỗ cho Index Server với Query Role có khả năng redundancy.

Mô hình năm máy chủ trong một farm - Five+ Servers Farm

Phổ biến nhất và đáp ứng tính sẵn sàng cao là mô hình “5+servers farm”, farm với máy chủ middle tier.


Máy chủ middle tier này giải quyết mọi vấn đề của mô hình “3,4-servers farm” bằng cách cung cấp tầng dành riêng cho Index Role và Application Role. Các máy chủ khác trong farm sẽ mở rộng tầng giữa, bằng cách chỉ định vai trò mới cho các máy chủ này – như Excel Calculation Services Role, và Microsoft Office Project Server 2007 Role.

Bảng tổng kết mô hình farm:

Farm Servers Performance Redundancy
3-4 

Index on WFE with Query on another boxApp Roles on WFE Index on Database, with Query on WFEApp Roles on WFE
5 App Roles on Middle TierDedicated Index Server on Middle Tier App Roles on WFEDedicated Index Server on Middle Tier
6 Dedicated Web Server for Crawling, outside NLBDedicated Index Server on Middle Tier App Roles on Middle Tier in NLBDedicated Index Server on Middle Tier

Để tối ưu hóa hiệu suất tổng thể của năm và nhiều máy chủ hơn của SharePoint Farm, cấu hình một Web Server dành riêng cho việc crawling nội dung, đặc biệt là khi một server farm chứa chứa hơn 500 gigabytes (GB) nội dung hoặc quá trình crawling nội dung phải thực hiện qua mạng WAN. Để đảm bảo rằng yêu cầu người dùng không bị ảnh hưởng bởi nội dung được crawling, loại bỏ máy chủ Web dành riêng từ cân bằng tải mạng xoay vòng. Điều này đặc biệt quan trọng trong môi trường toàn cầu trong đó các giờ cao điểm của một farm trong khu vực (khi công việc thu thập dữ liệu được lên lịch) trùng với giờ cao điểm của các farm trung tâm.

Hoạch định mô hình cho mạng Extranet - Plan extranet topology

Chọn các mô hình dựa trên yêu cầu cho người sử dụng bên ngoài. Mô hình này sẽ cung cấp một cơ sở mạng mở rộng cho các máy chủ ứng dụng và thông tin liên lạc giữa chúng.

Mô hình đơn giản nhất là “Edge firewall topology”, các bạn xem hình bên dưới – tham khảo từ trang TechNet.


Mô hình này áp dụng cho các farm nhỏ, khi không cần phải tách biệt các dịch vụ từ mạng nội bộ công ty và thông tin liên lạc an toàn giữa máy chủ farm. Mọi người dùng từ xa được tách ra khỏi farm bằng cách sử dụng ISA server đóng một vai trò của một proxy từ xa.

Đối với các farm lớn, khi an ninh của truyền thông là một ưu tiên, mô hình được đề nghị là "Back-to-back perimeter topology". Mô hình này rất linh hoạt và thích nghi với những thay đổi của mạng.


Lợi thế chính của mô hình này là nó cô lập các máy chủ farm trong một mạng vành đai riêng biệt. Các lớp logic tách biệt tất cả các máy chủ và truyền thông được kiểm soát - bất kỳ sự cố về an ninh nào chỉ ảnh hưởng đến một lớp cụ thể, chứ không phải toàn bộ farm. Truy cập của người dùng bên ngoài được cô lập vào mạng vành đai và người dùng cũng có thể được cô lập trong AD khác nhau cho truy cập từ xa và truy cập tại công ty

Có một số biến thể khác cho mô hình extranet, nhưng chủ yếu là tất cả chúng đều dựa trên "Back-to-back perimeter topology" với một số sửa đổi.

Thông tin chi tiết về các mô hình này, các bạn hãy tham khảo trong các tài liệu sau:

Best practices for team collaboration sites: http://technet.microsoft.com/en-us/library/cc850694.aspx
Planning an Extranet Environment for Office SharePoint Server: http://technet.microsoft.com/en-us/library/cc262400.aspx
“Logical Planning”


Hoạch định về site collections - Plan site collections
Hãy hoạch định số lượng site collections và sub sites trước - nội dung, vị trí, an ninh. Bắt đầu với site collections đơn giản và một số sub sites thay vì sau đó tạo ra các site collections, và cố gắng tránh tạo site collection mới nếu không có yêu cầu cho việc này. Lý do cơ cấu như vậy là mỗi site collection hoạt động như một ứng dụng mới, với phạm vi các tính năng, các mẫu và tìm kiếm được cô lập. Duy trì cấu trúc như vậy là dễ dàng hơn nhiều so với việc duy trì nhiều site collections.

Tổ chức site collection trên một vài content database - Organize site collection across several content databases

Đừng kết thúc với một content database lớn, vì việc tối ưu dữ liệu sẽ gây khó khăn trong trường hợp này. Đối với môi trường nhỏ và mục đích phát triển, một conent database thể là một sự lựa chọn thích hợp hơn. Tuy nhiên, cho các farm lớn, nên tạo ra một số các content database và tổ chức các site collections và các content database đó. Có một thông tin bổ ích sau, giúp các bạn khi hoạch định:

Giữ database size <100 GB, nếu không sẽ ảnh hưởng đến hiệu suất (theo khuyến cáo của Microsoft)
Tối ưu hóa dữ liệu sử dụng.
Đơn giản hóa việc sao sưu và phục hồi cho farm.
Linh động trong các chiến lược DR – Disaster Recovery.Tác giả Phạm Anh Vũ

    Blogger Comment
    Facebook Comment