注：
- 2つのノードで構成されるWindowsフェールオーバークラスタリング。
- 2つのSQLServerフェールオーバークラスターインスタンス。この構成により、ハードウェアが最適化されます。ノード1ではIN01が優先され、ノード2ではIN02が優先されます。
- ポート番号：IN01はポート1435でリッスンし、IN02はポート1436でリッスンします。
- 高可用性。両方のノードが相互にバックアップします。フェイルオーバーは、障害が発生した場合に自動的に行われます。
- クォーラムモードはノードとディスクの過半数です。
- 適切なLANのバックアップと、Veritasを使用して構成された定期的なバックアップ
はじめに
開発者やプロジェクトマネージャーが、新しいアプリケーションやサービスごとにSQLServerの新しいインスタンスを要求することは珍しくありません。仮想化やクラウドなどのテクノロジーによって新しいインスタンスの起動が簡単になりましたが、SQL Serverに組み込まれているいくつかの古くからの技術により、新しいサービスやアプリケーションに新しいデータベースを提供する必要がある場合に、所要時間を短縮できます。この状況は、組織が必要とするほとんどのSQLServerデータベースをサポートできる大規模なSQLServerクラスターを設計および展開できるDBAによって作成できます。この種の統合には、ライセンスコストの削減、ガバナンスの向上、管理の容易さなどの追加の利点があります。この記事では、SQLServerデータベースを統合する手段としてクラスタリングとスタッキングを使用するときに経験したいくつかの考慮事項に焦点を当てます。
クラスタリング
Windows Serverフェールオーバークラスタリングは、Windows Serverの多くのバージョンを生き延びてきた、非常によく知られている高可用性ソリューションであり、Microsoftはこれに投資して改善を続ける予定です。 SQLServerフェールオーバークラスターインスタンスはWSFCに依存しています。 SQLServerのStandardEditionとEnterpriseEditionはどちらもSQLServerフェールオーバークラスターインスタンスをサポートしていますが、StandardEditionは2つのノードのみに制限されています。データベースを単一のSQLServerFCIに統合すると、次のような利点があります。
- デフォルトのHA —クラスター化されたSQL Serverインスタンスにデプロイされたすべてのデータベースは、デフォルトで高可用性を備えています。クラスター化されたインスタンスが構築されると、HAの観点から新しいデプロイメントが事前に処理されます。
- 管理のしやすさ –多くのアプリケーションをサポートする1つのクラスター化されたインスタンスの構成、監視、および必要に応じたトラブルシューティングに時間を費やすことができるDBAは少なくなります。適切に、1つの大規模な環境を処理する場合、インスタンスの文書化もはるかに簡単になります。統合インスタンスを使用する場合、この構成を1つだけ実行する必要があるため、環境内のすべてのデータベースを処理するようにエンタープライズバックアップソリューションを構成するのが簡単になります。
- コンプライアンス –パッチ適用や強化などの重要な要件は、1回の管理作業で、多数のデータベースのダウンタイムを最小限に抑えて1回実行できます。当店では、データベースを災害のリスクから確実に保護するために、2つのデータセンターのクラスター化されたインスタンス間でトランザクションログ配布を使用しました。
- 標準化 –ショップの規模に応じて、1つまたは2つの環境のみを処理する場合、命名規則、アクセス管理、Windows認証、監査、およびポリシーベースの管理などの標準を適用する方がはるかに簡単です。
リスト1： インスタンスに関する情報を抽出する
-- Extract Instance Details
-- Includes a Column to Check Whether Instance is Clustered
SELECT SERVERPROPERTY('MachineName') AS [MachineName]
, SERVERPROPERTY('ServerName') AS [ServerName]
, SERVERPROPERTY('InstanceName') AS [Instance]
, SERVERPROPERTY('IsClustered') AS [IsClustered]
, SERVERPROPERTY('ComputerNamePhysicalNetBIOS') AS [ComputerNamePhysicalNetBIOS]
, SERVERPROPERTY('Edition') AS [Edition]
, SERVERPROPERTY('ProductLevel') AS [ProductLevel]
, SERVERPROPERTY('ProductVersion') AS [ProductVersion]
, SERVERPROPERTY('ProcessID') AS [ProcessID]
, SERVERPROPERTY('Collation') AS [Collation]
, SERVERPROPERTY('IsFullTextInstalled') AS [IsFullTextInstalled]
, SERVERPROPERTY('IsIntegratedSecurityOnly') AS [IsIntegratedSecurityOnly]
, SERVERPROPERTY('IsHadrEnabled') AS [IsHadrEnabled]
, SERVERPROPERTY('HadrManagerStatus') AS [HadrManagerStatus]
, SERVERPROPERTY('IsXTPSupported') AS [IsXTPSupported];
スタッキング
SQL Serverは、1台のサーバーで最大50個のシングルインスタンスをサポートし、WindowsServerフェールオーバークラスターで最大25個のフェールオーバークラスターインスタンスをサポートします。異なるバージョンのSQLServerを同じ環境にスタックして、異なるアプリケーションをサポートする堅牢な環境を提供できます。このような構成では、データベースのアップグレードは、ハードウェアが古くなるまで、データベースを1つのSQLServerインスタンスからまったく同じクラスター内の次のバージョンに昇格させるという形をとることができます。 SQL Serverをスタックする際に留意すべき重要な考慮事項の1つは、割り当てられるメモリの合計量がオペレーティングシステムで使用可能なメモリを超えないように、各インスタンスにメモリを割り当てる必要があることです。この方向のもう1つのポイントは、各インスタンスのSQLServerサービスアカウントにメモリ特権のロックページが必要であることを確認することです。メモリ内のロックページを割り当てると、SQL Serverがメモリを取得するときに、サーバー上の他のプロセスがメモリを必要とするときに、オペレーティングシステムがそのようなメモリを回復しようとしないことが保証されます。定義済みのSQLServerサービスアカウントの設定、MAX_SERVER_MEMORYの構成、およびメモリ内のロックページの権限の付与は、SQLServerインスタンスをスタックする際の重要なトリオです。
Microsoftは、CPUコアのペアごとに数千ドルを請求します。 SQL Serverインスタンスをスタックすると、インスタンスに同じCPUセットを共有させる（アセットを発汗させる）ことで、このライセンスモデルを活用できます。さまざまなバージョンのSQLServerをスタックできるため、たとえばSQLServer2016よりも古いバージョンを実行しているレガシーアプリケーションを処理できることは既に説明しました。異なるエディションのSQLServerを使用する場合は、この記事でGlenBerryが説明しているようにProcessorAffinityの使用を検討することをお勧めします。プロセッサ親和性は、メモリを制御するのと同じように、CPUリソースをインスタンス間で共有する方法を制御するためにも使用できます。スタッキングは、たとえばSAアカウントを使用する必要があるアプリケーションのセキュリティ上の懸念や、専用インスタンスを必要とするアプリケーションの構成上の懸念、またはそのようなオプションが特定の照合である場合にも対処します。共有TempDBのパフォーマンスに関する懸念は、すべてのデータベースを1つのクラスター化されたインスタンスにまとめるのではなくスタックしたいもう1つの理由です。
前に強調したクラスタリングの価値は、スタッキングによってさらに拡張されることに注意してください。たとえば、SQL Serverインスタンスに複数のFCIでパッチを適用する場合、すべてのFCIに一度にパッチを適用できます。
注意点
クラスタリングを使用する場合、特定の規則により、環境の管理と管理が少し簡単になり、アセットの機能が向上します。それらのいくつかに簡単に触れます：
- 現在のクライアントツール— SQL Server ManagementStudio2012を使用してSQLServer2016インスタンスを管理しようとすると、異常なエラーが発生する場合があります。エラーは、問題がクライアントツールのバージョンにあることを明確に示しているわけではありません。通常、インスタンスへの接続に使用するクライアントにはSQL Server ManagementStudio17.3インスタンスがあります。
- 命名規則—命名規則を使用すると、いつでも作業しているインスタンスを簡単に確認できます。エイリアスを使用すると、データベースへのアクセスが必要なエンドユーザーの長いインスタンス名を覚える負担をさらに減らすことができます。
- 優先ノード–フェールオーバークラスターマネージャーでSQL Serverの役割ごとに優先ノードを設定することは良い考えであり、すべてのクラスターノードの処理能力が利用されていることを確認するための良い方法です。当店では、優先ノードを設定した後、不注意によるフェイルオーバーが発生した場合に備えて、0500HRSと0600HRSの間でフェールバックするように役割を構成しました。
- トランザクションログ配布– FCIのディザスタリカバリを構成する場合、クラスターノードの名前やIPアドレスではなく、仮想名を使用してすべてのUNCパスを識別するのが理にかなっています。これにより、フェイルオーバーが発生した場合でも、物事が適切に機能し続けることが保証されます。また、両方のサイトのSQLServerエージェントアカウントがこれらのパスを完全に制御できるようにすることも非常に重要です。
リスト2： メールを使用したトランザクションログ配布の監視の構成
-- Create Table to Store Log Shipping Data
create table msdb dbo log_shipping_report
(status bit,
is_primary bit,
server sysname,
database_name sysname,
time_since_last_backup int,
last_backup_file nvarchar (500),
backup_threshold int,
is_backup_alert_enabled bit,
time_since_last_copy int,
last_copied_file nvarchar 500),
time_since_last_restore int,
last_restored_file nvarchar(500),
last_restored_latency int,
restore_threshold int,
is_restore_alert_enabled bit);
go
-- Create an SQL Agent Job with the Following Script
-- This will send an Email at Intervals determined by the job Schedule
-- The Job Should be Created on the Log Shipping Secondary Clustered Instance
-- This Job Requires that Database Mail is Enabled
truncate table msdb dbo log_shipping_report
go
insert into msdb dbo log_shipping_report
EXEC sp_help_log_shipping_monitor;
go
/*
select [server]
, database_name [database]
, time_since_last_copy [Last Copy Time]
, last_copied_file [Last Copied File]
, time_since_last_restore [Last Restore Time]
, last_restored_file [Last Restored File]
, restore_threshold [Restore Threshold]
, restore_threshold - time_since_last_restore [Restore Latency]
from msdb.dbo.log_shipping_report;
go
*/
DECLARE @tableHTML NVARCHAR(MAX) ;
DECLARE @SecServer SYSNAME ;
SET @SecServer = @@SERVERNAME
SET @tableHTML =
N'<H1><font face="Verdana" size="4">Transaction Logshipping Status from Secondary
Server ' + @SecServer + N'</H1>' +
N'<p style="margin-top: 0; margin-bottom: 0"><font face="Verdana" size="2">Please
find below status of Secondary databases: </font></p> ' +
N'<table border="1" style="BORDER-COLLAPSE: collapse" borderColor="#111111"
cellPadding="0" width="2000" bgColor="#ffffff" borderColorLight="#000000"
border="1"><font face="Verdana" size="2">' +
N'<tr><th><font face="Verdana" size="2">Secondary Server</th>
<th><font face="Verdana" size="2">Secondary Database</th>
<th><font face="Verdana" size="2">Last Copy Time</th>' +
N'<th><font face="Verdana" size="2">Last Copied File</th><th>
<font face="Verdana" size="2">Last Restore Time</th>' +
N'<th><font face="Verdana" size="2">Last Restored File</th><th>
<font face="Verdana" size="2">Restore Threshold</th>
<th><font face="Verdana" size="2">Restore Latency</th>' +
CAST ( ( SELECT td = lsr.server, '',
td = lsr [database_name], td = lsr time_since_last_copy '',
td = lsr last_copied_file td = lsr time_since_last_restore '',
td = lsr last_restored_file, '',
td = lsr restore_threshold '',
td =
case
when lsr restore_threshold
lsr time_since_last_restore < 0 then + '<td bgcolor="#FFCC99"><b><font face="Verdana"
size="1">' + 'CRITICAL' + '</font></b></td>'
when lsr restore_threshold
lsr time_since_last_restore < 20 and lsr restore_threshold
lsr time_since_last_restore > 0 then + '<td bgcolor="#FFBB33"><b><font face="Verdana
size="1">' + 'WARNING' + '</font></b></td>'
when lsr restore_threshold
lsr time_since_last_restore > 20 then + '<td bgcolor="#21B63F"><b><font face="Verdana
size="1">' + 'OK' + '</font></b></td>'
end , ''
FROM msdb dbo log_shipping_report as lsr
ORDER BY lsr.[database_name]
FOR XML PATH('tr'), TYPE ) AS NVARCHAR(MAX) ) +
N'</table>' + ' ';
EXEC msdb dbo.sp_send_dbmail
@recipients='[email protected]',
@copy_recipients='[email protected]',
@subject = 'Transaction Log Shipping Report',
@body = @tableHTML,
@body_format = 'HTML' ;
ディスクドライブ
SQL Serverインスタンスをスタックし、複数のデータベースをプロビジョニングすることの1つの副作用は、ドライブ文字が不足する傾向があることです。ボリュームマウントポイントを構成することで、この問題を回避しました。クラスタの役割に割り当てられた各ディスクは、インスタンスごとに1つまたは2つのドライブにのみ必要なドライブ文字を持つマウントポイントとして構成されます。クラスタでボリュームマウントポイントを使用する際の重要な注意点は、将来、同様のメンテナンスタスクを実行するためにマウントポイントを追加する必要がある場合、ドライブ文字を所有するプライマリドライブとマウントの両方を配置する必要があることです。クラスタのメンテナンスモードをポイントします。
この例では、割り当てられたクラスターの役割に基づいて、各ボリュームマウントポイントの名前を見つけました。処理するドライブが非常に多いため、たとえば、ディスクをストレージレベルで維持するのがそれほど面倒にならないように、ユーザーとストレージ管理者の両方が一意のディスクを識別する方法を見つける必要があります。
リスト3： ボリュームマウントポイントを使用する場合のディスクスペース使用量の監視
-- The Following Script Will Show Disk Space Usage from Within SQL Server -- It is Especially Helpful When Using Volume Mount Points -- Volume Mount Point Space Usage Can Also Be Monitored from Computer Management (OS Level) SELECT DISTINCT vs volume_mount_point , vs file_system_type , vs logical_volume_name , CONVERT(DECIMAL!18 2 vs total_bytes 1073741824.0) AS [Total Size (GB)] , CONVERT(DECIMAL(18 2 vs available_bytes 1073741824.0' AS [Available Size (GB)] , CAST(CAST(vs available_bytes AS FLOAT)/ CAST(vs total_bytes AS FLOAT) AS DECIMAL (18,2)) * 100 AS [Space Free %] FROM sys.master_files AS f WITH (NOLOCK) CROSS APPLY sys.dm_os_volume_stats f database_id, f [file_id]i AS vs OPTION (RECOMPILE);
データベースの展開
私たちの場合、私たちの戦略は、新しいデータベースが私たちの標準に従っていることを確認することでした。古いデータベースは、統合とアップグレードを同時に行っていたため、もう少し注意して処理されました。 Database Migration Assistantは、どのデータベースが私たちの神聖なSQL Server 2016インスタンスと確実に互換性がないかを教えてくれ、それらを安心して残しました（互換性レベルが100と低いものもあります）。デプロイされた各データベースには、そのサイズに応じて、データおよびログファイル用の独自のボリュームが必要です。データベースごとに個別のボリュームを使用することは、この統合された環境の潜在的な複雑さを考慮すると重要な、非常によく整理された環境を実現するためのもう1つのステップです。最後のステートメントは、アプリケーションが独自のデータベースを作成できるようにする場合、アプリケーションはモデルデータベースで使用されるのと同じファイルの場所を使用するため、DBAが展開の完了後にデータファイルを再配置する必要があることも意味します。
リスト4： ユーザーデータベースの再配置
-- 1. Set the database offline -- Be sure to replace DB_NAME with the actual database name ALTER DATABASE DB_NAME SET OFFLINE -- 2. Move the file or files to the new location. -- This means actually copying the datafiles at OS level -- You may also need grant the SQL Server Service account full permissions on the data file -- 3. For each file moved, run the following statement. ALTER DATABASE DB_NAME MODIFY FILE ( NAME = logical_name FILENAME = 'new_path\os_file_name') -- 4. Bring the database back online ALTER DATABASE database name SET ONLINE -- 5. Verify the file change: SELECT name, physical_name AS CurrentLocation, state_desc FROM sys.master_files WHERE database_id = DB_ID(N'DB_NAME');
アクセス管理
統合環境では、ログインなどのサーバーレベルのオブジェクトのリストが非常に長くなる可能性があることに同意してください。 Windowsグループを使用すると、このリストが短縮され、クラスター化された各インスタンスのアクセス管理が簡素化されます。通常、アクセスが必要なアプリケーション管理者、アプリケーションサービスアカウント、レポートをプルする必要があるビジネスユーザー、そしてもちろんデータベース管理者のために、ActiveDirectory上に作成されたグループが必要になります。 Windowsグループを使用する主な利点の1つは、Active Directoryでこれらのグループのメンバーシップを管理するだけで、アクセスを許可または取り消すことができることです。
アクセス管理の分野でのこの利点は、Windows認証でのみ可能であることは今ではおそらく明らかです。 SQLServerのログインをグループで管理することはできません。
リスト5： インスタンスログイン、データベースユーザー、およびそれらの役割
create table #userlist (
[Server Name] varchar(20)
,[Database Name] varchar(50)
,[Database User] varchar(50)
, [Database Role] varchar(50)
, [Instance Login] varchar(50)
, [Status] varchar(15)
)
go
insert into #userlist
exec sp_MSforeachdb @command1 ='
USE [?]
IF ''?'' NOT IN ("tempdb","model"J"msdb"J"master")
BEGIN
select @@servername as instance_name , ''?'' as database_name , rp.name as database_user , mp.name as database_role , sp.name as instance_login , case
when sp.is_disabled = 1 then ''Disabled'' when sp.is_disabled = 0 then ''Enabled'' end
[login_status]
from sys.database_principals rp
left outer join sys.database_role_members drm on (drm.member_principal_id = rp.principal_id)
left outer join sys.database_principals mp on (drm.role_principal_id = mp.principal_id)
left outer join sys.server_principals sp on (rp.sid=sp.sid)
where rp.type_desc in (''WINDOWS_GROUP'',''WINDOWS_USER'',''SQL_USER'')
END' go
select * from #userlist go
drop table #userlist
結論
統合、コストの最適化、および管理の容易さを実現する手段として、SQLServerインスタンスをクラスタリングおよびスタックすることで得られるメリットを非常に高いレベルで検討しました。大規模なハードウェアを購入できる場合は、このオプションを検討して、上記のメリットを享受できます。