CÁCH CẤU HÌNH SQL SERVER 2008 R2 EE Cluster


 

MÔ HÌNH CÀI ĐẶT

clip_image002[4]

CÀI ĐẶT:

clip_image004[4]

 

clip_image006[4]

 

GẶP LỖI:

clip_image010[4]

clip_image012[4]

clip_image014[4]

 

Tổng quan về Công nghệ CLustering
– Cluster được hiểu ngắn gọn là một nhóm các máy chủ chạy chung một dịch vụ nào đó nhằm phục vụ cho cân bằng tải (Load Balancing) và chịu lỗi (Fault Tolerant: Failover)
Việc cài đặt hệ thống Cluster phải đáp ứng được các yêu cầu sau:

+ Phải có độ tin cậy cao (Reliability)
+ Luôn đáp ứng được tính sẵn sàng (High Availability – HA)
+ Có khả năng mở rộng hệ thống khi cần thiết (Scalability)
– Cluster được dùng cho các ứng dụng Stateful Application (các ứng dụng hoạt động thường xuyên trong thời gian dài) bao gồm các Database Server như là: Microsoft SQL Server, Microsoft Exchange Server, File and Print Server…
– Các Node trong Cluster dùng chung một nơi lưu trữ dữ liệu có thể dùng công nghệ SCSI hoặc Storage Area Network (SAN) hay Network Attached Storage (NAS).

 

Điều kiện cần thiết để tiến hành cài đặt, cấu hình SQL CLustering
– Với 2 Nodes SQL Cluster cần tối thiểu 5 IP để cài đặt:
Node 1
+ Public NIC
+ Private NIC

Node 2
+ Public NIC
+ Private NIC

ClusterDatabase

ClusterWindows

ClusterMsDTC

– Tạo ổ đĩa lưu trữ trên hệ thống SAN phục vụ cho SQL Cluster
+ Quorum disk: Lưu cấu hình Cluster windows
+ MsDTC disk [Microsoft Distributed Transaction Coordinator]: Lưu các giao dịch, trao đổi qua lại giữa các Nodes
+ Database disk: Lưu dữ liệu

– Phải có hệ thống Domain Controller, hệ thống DNS Server

– Join các máy chủ Nodes Cluster vào hệ thống Domain

– Hệ điều hành sử dụng cho các Nodes Cluster phải là windows 64 bit, phiên bản Enterprise.

Cấu hình Failover Cluster Management của Server 2008

Mặc dù mọi phiên bản của Windows Server 2008 đều tích hợp tính năng Network Load Balance, tuy nhiên, chỉ có phiên bản Enterprise và Datacenter được tích hợp những tính năng Failover giúp cung cấp các cấp độ cao hơn của tính năng này.

Cluster cho phép người dùng thiết lập những tính năng sẵn có ở cấp độ cao cho các dịch vụ tổng hợp hay cho một số ứng dụng cụ thể. Công cụ Failover Cluster Management trong Windows Server 2008 cho phép người dùng tạo và quản lý nhiều Cluster.

Sau đây chúng ta sẽ đi tìm hiểu một số nét đặc trưng nhất về công cụ này.

Khái quát cài đặt và tác vụ

Để triển khai Clustering trong môi trường, cần thực hiện các bước sau:

1. Đảm bảo khả năng tương thích của phần cứng với Clustering của Windows Server 2008.

2. Cấu hình ổ đĩa trên vùng lưu trữ chia sẻ được kết nối và xuất hiện trên cả hai máy chủ.

3. Cài đặt tính năng Failover Clustering trên mỗi node Cluster sẽ sử dụng.

Sau khi đã hoàn thành các bước này, chúng ta có thể mở Failover Cluster Management Console bằng cách vào Start | Administrative Tools | Failover Cluster Management. Trong quá trình khởi chạy đầu tiên, chúng ta sẽ thấy một cửa sổ giống như hình 1 xuất hiện. Cửa sổ này không chứa bất kì Clustered Server đã được cấu hình nào.

clip_image015[4]

 

Hình 1: Failover Cluster Management.


Những tùy chọn cấu hình trên Console này rất giống với những công cụ quản trị khác của Microsoft, gồm một bảng điều hướng ở bên trái, một bảng làm việc với các đối tượng ở giữa, và một bảng Actions ở bên phải.

Bảng bên trái của Console hiển thị phân lớp Cluster và nhiều đối tượng khác nhau trong một Cluster, như Nodes (mục chủ), Services (dịch vụ), Storage (vùng lưu trữ), Networks (mạng), … Khi click vào một đối tượng trong bảng bên trái, thì nội dung của đối tượng đó sẽ hiển thị trong bảng bên phải. Ví dụ, khi click vào đối tượng Active Resources của một node nào đó, thì nội dung của nó sẽ hiển thị trong bảng bên phải cùng với State (trạng thái), Owner (chủ sử hữu), Group (nhóm), và nhiều thuộc tính khác.

Những tác vụ mà chúng ta có thể thực hiện với công cụ Failover Cluster Management bao gồm:

·         Tạo hoặc hủy một Cluster.

·         Thêm vào và gỡ bỏ node khỏi Cluster.

·         Têm ổ đĩa cho Cluster.

·         Bổ sung hay loại bo dịch vụ cho Cluster.

·         Cấu hình số lượng Rule cho ổ đĩa.

·         Kiểm tra các sự kiện liên quan tới mọi thành phần Cluster.

Menu

Công cụ Failover Cluster Management có 4 menu sau:

Menu File. Menu File chứa rất ít tác vụ trong Console này, chỉ có lệnh Options và Exit.
Action. Menu Action chứa hầu hết các tác vụ quản lý Cluster trong công cụ Failover Cluster Management. Những lệnh trong menu File sẽ thay đổi tùy thuộc vào đối tượng được lựa chọn trong những bảng trong Console. Trong mọi trường hợp, chúng ta có thể lựa chọn lệnh Open Connection từ menu File để mở kết nối tới một Cluster hiện có hay tạo một Cluster mới. Tốt nhất chúng ta nên làm việc với menu ngữ cảnh của từng đổi tượng để trành những lỗi phát sinh.

Menu View. Menu View cung cấp một số tùy chọn cho phép tùy biến giao diện của Management Console.

Menu Help. Sử dụng menu này để gọi các trợ giúp của Failover Cluster Management Console.
Ngoài ra, trên Console này còn chứa một thanh công cụ gồm các nút lệnh sau: Back, Forward, Up One Level (Không thường xuyên hiển thị), Show/Hide Console Tree, Properties, Refresh (Không thường xuyên hiển thị) và Help.

Cây Console

Mặc dù công cụ Failover Cluster Management không phải là một snap-in MMC, nhưng nó lại có giao diện và chức năng của một MMC. Trong cây Console (bảng bên trái) chứa kết nối Cluster mở được hiển thị trong cây phân cấp. Cây này bao gồm những đối tượng sau:

Services and Applications: Lựa chọn tùy chọn điều hướng này để mở danh sách các dịch vụ và ứng dụng đã được cấu hình trong Cluster.

Nodes: Mỗi node trong Cluster sẽ được hiển thị trong cây Console dưới tùy chọn Nodes (hình 2). Khi một node được lựa chọn, mọi thông tin chi tiết của node đó sẽ xuất hiện trong bảng làm việc (bảng giữa) của Console. Nếu muốn bổ sung một ổ đĩa vào Cluster, phải chuột lên tùy chọn này, trên menu ngữ cảnh xuất hiện chọn Add Node.


clip_image016[4]

Hình 2: Thông tin chi tiết của một Node trong Cluster.

 

Nếu như tất cả các vấn đề trên đều thực hiện tốt chúng ta sẽ chuyển sang bước tiếp theo kiểm tra cấu hình DHCP của máy chủ cài SQL Cluster.

       Trong phần cluster network configuration ở bước cài đặt, cần bỏ chọn đánh dấu DHCP và cần phải nhập tay cấu hình IP cho máy virtual cluster name mà chúng ta đang cài.(Trong quá trình cài, hệ thống ngầm định đã chọn DHCP và không tuỳ chọn 1 IP Virtual cho máy chủ đã chỉ định tên n/w ).

       Sau khi bỏ chọn DHCP và nhập IP bằng tay. Ta tiến hành tiếp việc chuẩn bị cài SQL Cluster.

 

 

Điều chỉnh lại các bước cài SQL Cluster 2008:

Thông thường khi cài bằng lệnh sau:

Setup.exe /PCUSource=C:\SP2 /SkipRules=Cluster_IsDomainController Cluster_VerifyForErrors /Action=InstallFailoverCluster

Sẽ xuất hiện lỗi sau:

The cluster resource ‘SQL Server’ could not be brought online. Error: The resource failed to come online due to the failure of one or more provider resources. (Exception from HRESULT: 0x80071736)

 

Cách sửa lỗi:

Cần phải Tạo một tài khoản máy tính “Computer Account” trong AD để truy cập và cài, cấu hình cho SQL Name.

 

Thêm SQL Server Agent Resource

       Dùng lệnh  command prompt và gõ lệnh sau:

Cluster restype “SQL Server Agent” /create /DLL: sqagtres.dll

Thay tất cả các giá trị từ  2 về thành  1 trong registery ở link:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft Microsoft SQL Server\MSSQL10.MSSQLSERVER\ConfigurationState

       Trong Failover Cluster Management dùng mục Add Resource để thêm cho phép chạy SQL Server Agent resource.

Bấm phải chuột trong resource và bấm chọn Properties. Thêm vào tên Virtual Server name (YOUR VIRTUAL NAME) và tên của Instance name (MSSQLSERVER)

Thêm cả SQL Server service as dependency for SQL Server Agent Service.

Sau đó bấm OK.

Bấm phải chuột vào Resource và chọn “bring this resource online”

Phải đảm bảo mục Resource là Online, bạn sẽ đi tiếp và thêm  Second node

Để thêm các Nodes bổ sung

Hãy tời bản vá lỗi service packs bằng lệnh sau:

SQLServer2008SP2-KB979450-x64-ENU.exe /x:C:\SP2

Hãy chạy các service pack để cài các files trong máy, sẽ có các họp thoại thông báo việc các file chưa được cài. Bạn cũng có thể chạy riêng các file sau để cài:

C:\SP2\x64\setup\1033\sqlsupport.msi

Sao chép từ bộ đĩa cài SQL tới thư mục local disk (C:\SQL2008)

Chạy Setup.exe từ  bộ đĩa cài SQL Server 2008 có dung tham số  /PCUSource, cũng bỏ qua kiểm tra cho Domain Controller và các lỗi lỗi. Ví dụ:

Setup.exe /PCUSource=C:\SP2 /SkipRules=Cluster_IsDomainController Cluster_VerifyForErrors /Action=AddNode

 

Sau khi cài xong hoàn chỉnh SQL 2008 Server Cluster thì cần kiểm tra hoạt động của Cluster Log:

In Windows 2003 Failover Clustering, the cluster service on each node constantly writes to a live debug output file. These files are located in the %SystemRoot%\Cluster folder on each node in the cluster and the name of the file is CLUSTER.LOG. The cluster log is local and specific to each node’s cluster service. Each node has a unique log file that represents its views and actions. This file is in a basic text format and can be easily viewed with Word, Notepad, etc.

In Windows Server 2008, a change was made to make the cluster debug logging mechanism more in line with how the rest of Windows handles event logging. The Win 2003 legacy CLUSTER.LOG text file no longer exists. In Win 2008 the cluster log is handled by the Windows Event Tracing (ETW) process. This is the same logging infrastructure that handles events for other aspects you are already well familiar with, such as the System or Application Event logs you view in Event Viewer.

For more information on the topic of Windows Event Tracing, see the following MSDN articles:

Improve Debugging and Performance Tuning With ETW

Event Tracing

About Event Tracing

How to Generate a Cluster Log

First we need to look at the cluster logs in some user friendly format. You can run the following commands to generate a text readable version of the ETL files. We’ll talk more about ETL files in a bit. The trace sessions are dumped into a text file that looks very similar to the legacy CLUSTER.LOG

If you are running Windows Server 2008, you can use the ‘cluster.exe’ command line . If you are running Windows Server 2008 R2, you can use either ‘cluster.exe’ command line or the cluster PowerShell cmdlets.

Command Line

c:\>cluster log /gen

Some useful switches for ‘cluster log /gen’ are:

Switch

Effect

c:\>cluster log /gen /COPY:”directory

Dumps the logs on all nodes in the entire cluster to a single directory

c:\>cluster log /gen /SPAN:min

Just dump the last X minutes of the log

c:\>cluster log /gen /NODE:”node-name

Useful when the ClusSvc is down to dump a specific node’s logs

For more detailed information on the ‘cluster log /gen’ command, see the TechNet article here.

Powershell

C:\PS> Get-ClusterLog

Some useful switches for ‘Get-ClusterLog’ are:

Switch

Effect

C:\PS> Get-ClusterLog –Destination

Dumps the logs on all nodes in the entire cluster to a single directory

C:\PS> Get-ClusterLog –TimeSpan

Just dump the last X minutes of the log

C:\PS> Get-ClusterLog –Node

Useful when the ClusSvc is down to dump a specific node’s logs

For more detailed information on the ‘Get-ClusterLog’ cmdlet, see the TechNet article here.

Failover Cluster Tracing Session

You can see the FailoverClustering ETW trace session (Microsoft-Windows-FailoverClustering) in ‘Reliability and Performance Monitor’ under ‘Data Collector Sets’, ‘Event Trace Sessions.

clip_image018[4]

Cluster event tracing is enabled by default when you first configure the cluster and start the cluster service. The log files are stored in:

%WinDir%\System32\winevt\logs\

The log files are stored in an *.etl format.

Every time a server is rebooted, we take the previous *.etl file and append it with a 00X suffix

By default, we keep the most recent three ETL files. Only one of these files is the active or “live” log at any given time.

Format in Windows Server 2008

ClusterLog.etl.001
ClusterLog.etl.002
ClusterLog.etl.003

Format in Windows Server 2008 R2

Microsoft-Windows-FailoverClustering Diagnostic.etl.001
Microsoft-Windows-FailoverClustering Diagnostic.etl.002
Microsoft-Windows-FailoverClustering Diagnostic.etl.003

The default size of these logs is 100MB each. Later in this post, I’ll explain how to determine if this size is adequate for your environment.

The important thing to understand about the cluster logs is we use a circular logging mechanism. Since the logs are a finite 100MB in size, once we reach that limit, events from the beginning of the current or “live” ETL log will be truncated to make room for events at the end of the log.

clip_image020[4]

Here’s an example of the timeframes captured in a series of ETL files.

In this example, every night the server is rebooted at midnight. The three most recent ETL logs would look like this:

clip_image022[4]

REBOOT

clip_image024[4]

REBOOT

clip_image026[4]

The ETL.001 file is the active file being used by the live cluster service to write debug entries. Let’s say there were many entries being written to the current trace session file and we hit the 100MB limit at 3pm. At that point, events from 12am to 3am were truncated to make room for additional entries in the log. At that point, the ETL.001 log would look like this:

clip_image028[4]

clip_image030[4]Now I want to view the cluster logs in some text readable format so I run either the ‘cluster log /gen’ command or the ‘Get-ClusterLog’ cmdlet

These commands take all the ETL.00X files and “glue” them together in the order they were created to make one contiguous text file.

<- LIVE TRACE SESSION

The file that gets created is located in \%WinDir%\Cluster\Reports\ and is called CLUSTER.LOG

If you were looking at the debug entries in the CLUSTER.LOG file, you might notice that since we glued all three logs together, there is an apparent gap in the CLUSTER.LOG from 11:59pm on 1/2 to 3am on 1/3. The assumption may be that either there is information missing during that time or there was nothing being logged. The missing time is not in and of itself a problem, just a side effect of concatenating all three logs together.

clip_image032[4]

How Large Should I Set My Cluster Log Size?

So now that you understand why there may be “gaps” in the cluster debug log, let’s discuss how this relates to understanding how large your cluster log size should be. The first thing you need to determine is “How much time is covered in each ETL file?”. If you were looking at the CLUSTER.LOG text file from the above examples, you could see that the most recent ETL.001 file contained about 12 hours of data before it was truncated. The other ETL files contain about 24 hours of data. When we are talking about the cluster log size, we are ONLY talking about the live ETL trace session.

The amount of data written to the ETL files is very dependent on what the cluster is doing. If the cluster is idle, there may be minimal cluster debug logging, if the cluster is recovering from a failure scenario, the logging will be very verbose. The more data being written to the ETL file, the sooner it will get truncated. There’s no one “recommended” value for the size of the cluster log that will fit everyone.

Since the default cluster log size in Windows Server 2008 is 100MB, the above example shows that 100MB ETL file covers about a 12-24 hour timeframe. This means if I am troubleshooting a cluster issue, I have 12 hours from the failure to generate a cluster log or risk information being truncated. If it may not be feasible to generate a cluster log that soon after a failure, you should consider increasing the size of the cluster log. If you changed the size of the cluster log to 400MB, you are accounting for the need to have at least 2 days (12 hours X 4) of data in the live ETL file.

Why Should I Care About All This?

While reading cluster logs may not be something you generally do in your leisure time, it’s a critical log Microsoft Support uses to troubleshoot cluster issues. If there’s any other message I could convey here it’s that in order for us to do a good job of supporting our customers, we need to have the data available. We often get customers who open a case to try and figure out why their cluster had problems and those problems occurred over a week ago. As hard of a message it is to deliver, without the complete cluster log, root cause analysis becomes extremely difficult. If you intend to open up a support case with Microsoft, keep the following in mind.

  • The sooner after the failure we can capture the cluster logs, the better. The longer you wait to open a case and have us collect diagnostic information, the greater chance the cluster log will truncate the timeframe we need.
  • If you can’t open a case right away, at least run the ‘cluster log /gen’ or the ‘Get-ClusterLog’ command and save off the cluster log files for when you do have a chance to open a case.
  • It is generally recommended that your CLUSTER.LOG have at least 72 hours’ worth of continuous data retention. This is so that if you have a failure occurs after you went home on Friday; you still have the data you need to troubleshoot the issue on Monday morning.

How to Change the Cluster Log Size

Changing the default cluster log size is fairly straightforward.

First, open an elevated command prompt and type the following:

C:\>cluster /prop

This will output the current properties of the cluster.

clip_image034[4]

To change the cluster log size, open an elevated command prompt and type the command:

Powershell

C:\PS>Set-ClusterLog –Size X

Command Line

c:\>cluster log /Size:X

Where X is the size you want to set in MB. Note in the above screenshot, the default is 100.

How to Change the Detail Verbosity of the Cluster Log

In the above screenshot, the default cluster log level (ClusterLogLevel) is 3. Generally, you shouldn’t need to change the default level unless directed by a Microsoft Support Professional. Using debug level ‘5’ will have a performance impact on the server.

Level

Error

Warning

Info

Verbose

Debug

0 (Disabled)

         

1

X

       

2

X

X

     

3
(Default)

X

X

X

   

4

X

X

X

X

 

5

X

X

X

X

X

To change the cluster log level, open an elevated command prompt and type the command:

Powershell

C:\PS>Set-ClusterLog –Level X

Command Line

c:\>cluster log /Level:X

Where X is the desired log level.

About thangletoan

Hallo Aloha

Posted on 12/09/2012, in Công nghệ và Giáo dục, Chính sách CNTT, Microsoft, Microsoft Access Database, Microsoft Database, Microsoft Database Cluster, SQL Server Cluster and tagged . Bookmark the permalink. Để lại bình luận.

Gửi phản hồi

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Log Out / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Log Out / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Log Out / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Log Out / Thay đổi )

Connecting to %s

%d bloggers like this: