どちらも、DNSを触り始めた人がほぼ必ず通る疑問です。そして後者は、後から変えるのが非常に難しいのに、最初に何となく決められてしまいがちな問題でもあります。

前回（第1回）は、DNSの3つの登場人物と、キャッシュDNSがルートから順に「紹介」をたどって答えを見つける流れを見ました。第2回では、その紹介の仕組みである委任を中心に、名前の住所録は誰が管理しているのかを掘り下げます。

ドメイン名の木構造

DNSの名前は、ルート（根）を頂点とする木構造（ツリー）になっています。

www.example.jpは、ドットで区切られたwww、example、jpという3つのラベルでできています。右から左へ読むと、木を根から枝先へたどれます。

• ルートの下に、jpやcomなどのトップレベルドメイン（TLD）がある
• その下に、組織が登録したexample.jpがある
• さらにその下に、組織が自由に作るsales.example.jpやwww.example.jpが続く

英語の住所と同じく、左が細かい単位、右が大きい単位です。同じ親の下で重複しなければよいので、wwwという名前は世界中の組織がそれぞれ使えます。

名前の長さには制限があります。

• ラベル：63オクテット以内
• 名前全体：255オクテット以内（テキストで書くと最大253文字）

使える文字は、ホスト名としては英数字とハイフンが基本です（日本語などの扱いは、この記事の後半で説明します）。

ルートとTLD

木の頂点にあるルートと、その直下のTLDを整理します。

2026年9月時点で、ルートゾーンには約1,440のTLDがあります（IANAのTLD一覧）。新gTLDの2回目の募集は、2026年4月30日から8月12日まで受け付けられました。

見慣れないTLDも実在しうる、というのがポイントです。社内で勝手なTLDを使うと、後から同名のTLDが登録されて衝突する恐れがあります（後半の「内部用ドメイン名の選び方」で詳しく扱います）。

ルートサーバーは13台ではない

ルートゾーンの情報を配るのがルートサーバーです。

ルートサーバーはa.root-servers.netからm.root-servers.netまでの13の名前（13系統）で表され、12の組織が運用しています。13という数は、初期のDNSでルートサーバーの一覧が512バイトのUDPの応答1つに収まるように決められた名残です。

ただし、実際のサーバーが13台しかないわけではありません。各系統はエニーキャストという仕組みで同じIPアドレスを世界中の拠点から経路広告しており、問い合わせは経路上もっとも近い拠点に届きます。2026年9月時点で稼働中の拠点は約2,000あり、日本国内にもあります。1か所が攻撃や障害で止まっても、全体は止まりません。

もう1つ大事なのは、ルートサーバーが返すのは、ほとんどが「そのTLDは誰々に聞いて」という紹介だということです。ルートサーバーがすべての名前を知っているわけではありません。

ポイント
・ルートサーバーは13系統（a〜m）で、12の組織が運用する
・エニーキャストで約2,000拠点に分散し、近い拠点が応答する
・ルートが返すのは答えではなく、TLDのサーバーの紹介

FQDNと末尾のドット

FQDN（完全修飾ドメイン名）とは、ルートまでのラベルを省略せずに書いた名前です。正式には、ルートを表す末尾のドットを付けてwww.example.jp.と書きます。

普段は末尾のドットを省略しますが、DNSではドットの有無で意味が変わる場面があります。

1つ目はゾーンファイルです。BINDのゾーンファイルでwww.example.jpとドットを付け忘れると、ゾーン名が補われてwww.example.jp.example.jp.になってしまいます（第5回で詳しく扱います）。

2つ目は問い合わせです。OSやツールは、ドットで終わらない名前にsearchドメイン（DNSサフィックス）を付けて試すことがあります。たとえばsearchドメインがcorp.example.jpだと、www.example.comを引いたときにwww.example.com.corp.example.jpのような余計な問い合わせが発生します（第3回）。同名のレコードがあると、違う答えが返ることもあります。

調査では末尾にドットを付ける習慣をつけましょう。末尾の「.」は「ここで終わり」の印で、何も補わせません。

ドメインとゾーンの違い

冒頭の疑問に答えます。

• ドメイン：名前の木の一部分。ある名前と、その下のすべての名前を指す
• ゾーン：1組の権威DNSサーバーがまとめて管理する単位

example.jpドメインには、www.example.jpもpc01.sales.example.jpも含まれます。

ここで、example.jpの管理者がsales.example.jpを営業部のDNSサーバーに任せた（委任した）とします。すると、example.jpゾーンにはsalesより下の名前は含まれず、sales.example.jpは別のゾーンになります。この境目をゾーンカットと呼びます。

会社にたとえると、ドメインは「全部署を含めた組織全体」、ゾーンは「台帳を管理する担当の範囲」です。pc01やpc02はexample.jpドメインの一員ですが、example.jpの台帳には載っていません。example.jpの台帳にあるのは、salesへの委任（NS）だけです。

委任をしなければ両者の範囲は一致するので、違いを意識しにくいのですが、委任や条件付きフォワーディングの設計には、この区別が欠かせません。

ポイント
・ドメインは名前の木の範囲、ゾーンは管理（台帳）の単位
・委任した部分は親のゾーンから外れ、別のゾーンになる
・委任しなければ、ドメインとゾーンの範囲は一致する

委任（NS）とグルー

委任とは、親のゾーンが「この名前より下は、このサーバーに聞いて」と、子のゾーンの権威DNSサーバーを示すことです。具体的には、親のゾーンに、子のゾーン名のNSレコードを置きます。

jpゾーンにはexample.jpのNSとしてns1.example.jpなどが登録されており、jpのサーバーはこれを「紹介（リファーラル）」として返します。

グルーが必要な理由

ここで、ns1.example.jpがexample.jpの中にあると困ったことが起きます。ns1.example.jpのアドレスを知るにはexample.jpに聞く必要があり、example.jpに聞くにはns1.example.jpのアドレスが必要…という堂々巡りです。

そこで、親のゾーンにNSの名前のアドレス（A・AAAA）も置いて、紹介と一緒に返します。これをグルー（接着剤）と呼びます。RFC 9471（2023年）は、こうしたグルーを必ず応答に含め、入りきらなければTCビットを立てるよう求めています（TCビットは第4回）。

親と子のNSは一致させる

図のとおり、NSレコードは親（jp）と子（example.jp）の両方にあります。親のNSは紹介のための写しで、正本は子のゾーンにあります。

この2つが食い違うと、一部の問い合わせだけが失敗するという、非常に分かりにくい障害の原因になります（第7回）。権威DNSサーバーを入れ替えたときなどに、片方だけ直して起きがちです。

ポイント
・委任は、親のゾーンに子のゾーンのNSレコードを置くこと
・NSの名前が子のゾーンの中にあるときは、親にアドレス（グルー）も置く
・親と子のNSの食い違いは、断続的な障害の原因になる

レジストリ・レジストラ・Whois／RDAP

では、親のゾーン（たとえばjp）にある自社のNSは、誰がどうやって登録しているのでしょうか。ドメイン名を取得するときの関係者を整理します。

• レジストリ：TLDのゾーンと登録データベースを管理する組織。.jpはJPRS、.comはVerisign
• レジストラ：利用者から登録の申し込みを受けて、レジストリに取り次ぐ事業者。.jpでは「指定事業者」と呼ぶ
• 登録者：レジストラと契約する（自社）

登録者は、権威DNSサーバーの情報（NS）もレジストラ経由で親のゾーンに登録します。つまり、親ゾーンのNSは自社のDNSではなく、レジストリの台帳にあるのです。

そのため、権威DNSサーバーを変えるときは、自分のゾーンだけでなく、レジストラの画面で親のNSも変える必要があります。ここを忘れると、せっかく新しいDNSサービスにゾーンを作っても、世界中のキャッシュDNSは古いサーバーに聞きに行き続けます。

WhoisからRDAPへ

登録者や有効期限などの登録情報は、長くWhois（TCP/43）で公開されてきました。しかしgTLDでは、2025年1月28日にWhoisの提供義務がなくなり、HTTPSでJSONを返すRDAPが正式な手段になりました。ccTLDの扱いは各レジストリによります。

なお、期限切れのドメインは第三者に取得される恐れがあり、更新の管理も重要です（第9回）。

ポイント
・レジストリはTLDを管理し、レジストラは登録を取り次ぐ
・権威DNSを変えるときは、レジストラ経由で親のNSも変える
・gTLDの登録情報の照会は、2025年1月にWhoisからRDAPへ移行

内部用ドメイン名の選び方

社内のActive Directoryなどに使うドメイン名は、後から変えるのが非常に難しく、最初の選び方が重要です。

避けるべきなのは、登録していない勝手な名前です。

.local はmDNS用に予約されている

たとえば.localは、RFC 6762でマルチキャストDNS（mDNS）用に予約されています。macOSやLinux（Avahi）、プリンターなどは、.localで終わる名前をDNSサーバーに聞かず、LAN内のマルチキャスト（224.0.0.251:5353）で解決しようとします。

その結果、図のように同じ名前でも、機器によって聞き方が違う状態になり、再現しにくい障害の原因になります。「Windowsからは引けるのに、Macからは引けない」という相談の裏に、.localが隠れていることは珍しくありません。

勝手な名前の問題はほかにもある

• 本物のTLDと衝突する：社内で使っていた名前が、後から本物のTLDとして登録されて衝突した例があります（2014年に委任された.devなど）
• 公的な証明書が取れない：公的な認証局は、登録されていない内部の名前に対してサーバー証明書を発行しません
• Microsoftも推奨していない：MicrosoftはADのドメイン名に、登録済みのドメイン名またはそのサブドメインを使うよう勧めています

新しく決めるなら、自社ドメインのサブドメイン（corp.example.jp など）にしましょう。

候補の比較

推奨は自社ドメインのサブドメインです。外部に公開しない名前でも、親ドメインを保有していれば衝突せず、証明書も取れます。

なお、AWSのEC2の内部名（ec2.internalなど）のように、.internalは既にクラウドでも使われています。社内外で同じ名前に別の答えを返す構成（スプリットホライズン）は第7回、ADドメイン名の決め方は第12回の演習で扱います。

国際化ドメイン名（Punycode）

最後に、日本語のドメイン名です。DNSのホスト名に使える文字は、もともと英数字とハイフンに限られます。

そこで「日本語.jp」のような国際化ドメイン名（IDN）は、DNSの中ではPunycode（RFC 3492）という方式でASCII文字に変換し、先頭にxn--を付けた形で扱います。たとえば日本語.jpはxn--wgv71a119e.jpになります。

• 変換はブラウザーなどのアプリケーションが行う（IDNA2008、RFC 5890〜5893）
• ゾーンには変換後の形で登録する
• そのため、ゾーンファイルやdigの結果ではxn--で始まる文字列として現れる

DNSの中はASCII（xn--）だけで、日本語は表示のための姿、と覚えておくとすっきりします。

ホモグラフ攻撃に注意

注意したいのは、見た目のよく似た文字を使った偽のドメイン名（ホモグラフ攻撃）です。たとえばラテン文字の「a」とキリル文字の「а」は見分けがつきません。先頭だけキリル文字にしたаpple.comは、DNSの中ではxn--pple-43d.comという別の名前です。

主要なブラウザーは、危険な文字の混在を見つけるとPunycodeのまま表示するなどの対策をしています。

考えてみよう

1. 自社ドメインのNSが、親（TLD）側と自社の権威DNS側で一致しているかを確かめるには、どこに何を問い合わせればよいでしょうか。
2. 社内で使っているドメイン名は、どのパターン（自社のサブドメイン、.local、独自の名前など）ですか。社内のサーバー証明書はどう発行していますか。
3. 自社ドメインの有効期限、更新の担当者、支払い方法を知っていますか。担当者が異動したらどうなりますか。

ヒント：この記事の「委任とグルー」「レジストラ」「内部用ドメイン名の比較」が手がかりです。親と子のNSは、dig（WindowsではResolve-DnsName -Type NS -Server）で両方に聞くと比べられます（第8回）。

まとめ

• DNSの名前はルートを頂点とする木構造。右から左へ読むと根から枝先へたどれる
• ルートサーバーは13系統・約2,000拠点。ルートが返すのは答えではなく紹介
• 調査では末尾にドットを付けて、searchドメインの付加を避ける
• ドメインは名前の範囲、ゾーンは管理の単位。委任した部分は別ゾーンになる
• 委任は親にNSを置くこと。必要ならグルーも置き、親と子のNSは一致させる
• 社内のドメイン名は.localではなく自社ドメインのサブドメインに

次回は、キャッシュDNSサーバーが実際にどう答えを探し、どれだけの間覚えておくのか（キャッシュとTTL）を扱います。

連載「DNS入門」全12回

1. DNSとは？名前解決の全体像と3つの登場人物
2. ドメイン名の階層と委任（この記事）
3. 名前解決の流れ
4. DNSメッセージとトランスポート
5. リソースレコード 前編
6. リソースレコード 後編
7. 権威DNSサーバーの運用
8. コマンドで調べる
9. DNSのセキュリティ
10. クラウド・社内環境のDNS
11. DNSトラブルシュート
12. DNS設計演習

DNSは、Webの閲覧、メールの配送、Active Directoryへのログオン、クラウドのサービス間の通信など、ほとんどすべての通信の最初に動いている仕組みです。普段は意識されませんが、止まったり、誤った答えを返したりすると、原因の分かりにくい障害として表に出てきます。

この連載では、名前を引いたときに裏側で何が起きているかを、登場人物と委任の流れから順に説明します。そのうえで、dig（WindowsではPowerShellのResolve-DnsName）で応答を読んで障害を切り分ける方法、ゾーンやTTLを安全に設計・変更する方法、DNSSECや暗号化DNSといった守り方、Route 53やAD統合DNSといったクラウド・社内環境での使い方までを扱います。仕様や数値は2026年9月時点の情報に合わせています。

第1回は、DNSの全体像です。

この図のとおり、どの通信もまず名前を引いて答え（IPアドレスなど）を得てから、本来の通信が始まります。裏を返すと、DNSが止まると、どの通信も入口で止まるということです。

この連載の進め方

全12回で、次の順に進めます。第1回〜第3回が土台です。特に今回の「登場人物」と、第2回の「委任」は、この後のすべての回で使うので、確実に押さえてください。

コマンドの詳しい使い方は第8回にまとめ、それまでの回では説明に必要な範囲でdigの出力を示します。各回の最後にある「考えてみよう」は、自分の職場や自宅の環境を思い浮かべながら答えてみてください。

hostsファイルからDNSへ

コンピューター同士はIPアドレスで通信しますが、数字の並びは人間には覚えにくいものです。

そこで初期のインターネット（ARPANET）では、名前とアドレスの対応を1つのファイル（HOSTS.TXT）にまとめてSRI-NICが一元管理し、各ホストが定期的にダウンロードしていました。全員が同じ電話帳のコピーを持つ状態です。

しかしホストが増えると、更新の手間、ファイルの肥大化、名前の重複が限界に達しました。そこで1983年のRFC 882・883で生まれ、1987年のRFC 1034・1035で現在の形になったのがDNSです。

DNSは電話帳を分割し、各組織が自分の部分だけを管理する分散型のデータベースです。上の図の下半分のように、ルートの下のjpはJPRSが、comはVerisignが管理し、その下のexample.jpはA社が、example.comはB社が、それぞれ自分の部分だけを管理します。「1か所に集める方式」から「各組織が自分の部分を持つ方式」への転換が、DNSのいちばん大きな発想です。

hostsファイルは今も残っている

なお、hostsファイルは今もOSに残っています。

• Linux / macOS：/etc/hosts
• Windows：C:\Windows\System32\drivers\etc\hosts

多くの場合、hostsはDNSより先に参照されます。検証のために一時的に書いた行を消し忘れると、DNSをいくら直しても、そのサーバーだけ古いアドレスに接続し続ける、ということが起きます。「このサーバーだけおかしい」ときは、まずhostsを疑う習慣をつけておくと役に立ちます。

ポイント
・昔は1つのファイル（HOSTS.TXT）を全員に配って使っていた
・DNSは名前の管理を分割し、各組織が自分の部分を持つ分散データベース
・hostsは今も残り、DNSより先に参照される。書き残しに注意

名前解決とは：通信は「2段階」で行われる

名前解決とは、www.example.jpのような名前から、通信に必要なIPアドレスなどの情報を求めることです。

• 正引き：名前 → アドレス（例：www.example.jp → 192.0.2.10）
• 逆引き：アドレス → 名前（例：192.0.2.10 → www.example.jp）

ブラウザーでWebサイトを開くときは、まず名前解決でアドレスを得て、次にそのアドレスへ接続するという2段階の通信が行われます。図の①②が名前解決、③が本来の通信です。

この2つは別々の通信です。そのため「つながらない」と言われたら、名前解決で失敗しているのか、その後の接続で失敗しているのかを最初に切り分けます。①②が失敗すると、③は始まりもしません。逆に、名前解決は成功しているのに③で失敗しているなら、DNSではなくネットワークやサーバー側の問題です。

DNSが答えるのはアドレスだけではない

DNSが答えるのはIPアドレスだけではありません。

• メールの配送先（MX）
• Active Directoryのドメインコントローラーの場所（SRV）
• 送信ドメイン認証の情報（TXT）

など、さまざまな情報（リソースレコード、第5回・第6回で解説）を引けます。

また、逆引きも軽視できません。SSHのログインが遅い、vSphereの構築が失敗するといった問題は、逆引きが引けないことが原因になっている場合があります（第10回・第11回）。

ポイント
・名前解決と、その後の本来の通信は別。まずどちらで失敗したかを見る
・正引き（名前→アドレス）と逆引き（アドレス→名前）がある
・アドレス以外に、メールの配送先やサービスの場所なども引ける

DNSの3つの登場人物

DNSを理解するうえで、いちばん大事なのがここです。DNSの登場人物は3種類です。

1. スタブリゾルバー（依頼者）
PCやサーバーのOSに組み込まれた、問い合わせを出す側の部品です。自分では答えを探さず、設定されたDNSサーバーに「調べてきて」と頼むだけです。

2. フルサービスリゾルバー（受付係）
一般にはキャッシュDNSサーバーと呼ばれます。頼まれた名前について、ルートから順に答えを持つサーバーを探し回り、得た答えを一定時間覚えておきます（キャッシュ）。「代わりに探します」という役です。

3. 権威DNSサーバー（台帳係）
自分が担当する範囲（ゾーン）の「正解」を持ち、その範囲についてだけ答えます。「担当の範囲だけ答えます」という役です。

たとえるなら、スタブリゾルバーは依頼者、フルサービスリゾルバーは調べ物を代行する受付係、権威DNSサーバーは各部署の台帳係です。

ここで大事なのは、PCのネットワーク設定に書く「DNSサーバー」は、原則としてフルサービスリゾルバー（キャッシュDNS）だということです。PCは権威DNSサーバーに直接は聞きません。必ず受付係を通して聞きます。

ポイント
・問い合わせる側（スタブ）、調べ回る側（フルサービス）、答えを持つ側（権威）
・PCに設定するDNSサーバーは、原則としてフルサービスリゾルバー
・権威DNSサーバーは、担当するゾーンについてだけ答える

1回の名前解決の全体の流れ

では、PCがwww.example.jpを初めて引く場合を追ってみましょう。

1. ① PCのスタブリゾルバーは、設定されたキャッシュDNSサーバーに問い合わせます。
2. キャッシュに答えがなければ、キャッシュDNSサーバーは ② ルートサーバーに聞きます。
3. ルートは答えを持っていませんが、③「jpのことはjpのサーバーに聞いてください」と担当を紹介します（委任、第2回）。
4. 続いて ④ jpのサーバーに聞くと、⑤ example.jpのサーバーを紹介されます。
5. ⑥ example.jpの権威DNSサーバーに聞くと、⑦ ようやく「192.0.2.10です」という答えが返ります。
6. キャッシュDNSサーバーは ⑧ その答えをPCに返し、同時にキャッシュに保存します。

面白いのは、②④⑥はどれも同じ質問「www.example.jpのAレコードは？」だという点です。キャッシュDNSは同じ質問を投げ続け、答えが見つかるまで紹介をたどります。

電話のたとえでいえば、受付係が本部、支部、担当部署と順に電話をかけ、担当者の答えを依頼者に伝える流れです。図の青（①⑧）が再帰問い合わせ、オレンジ（②〜⑦）が反復問い合わせで、この違いは第3回で詳しく扱います。

そして、2回目以降はキャッシュから答えるため、②〜⑦は行われません。インターネット全体でDNSが軽快に動いているのは、このキャッシュのおかげです。

ポイント
・キャッシュDNSが、ルート→TLD→担当ゾーンの順に紹介をたどる
・各段階の「紹介」が委任。最後に権威DNSが答えを返す
・答えはキャッシュされ、2回目以降は②〜⑦が省かれる

用語の整理（RFC 9499）

DNSは歴史が長いので、同じものがいろいろな名前で呼ばれています。この連載での呼び方と、RFC 9499（2024年、RFC 8499を置き換えたDNSの用語集）の用語、現場での呼び方を対応させておきます。

注意したいのは、単に「DNSサーバー」と言うと、キャッシュDNSと権威DNSの両方を指してしまうことです。会話やチケットで「DNSサーバーを変更しました」と出てきたら、「キャッシュ」の話か「権威」の話かを必ず確かめましょう。ここを取り違えると、話がまったく噛み合いません。

身の回りのDNS

普段使っている端末は、どのキャッシュDNSに聞いているのでしょうか。場面ごとに整理してみます。

特に最後のブラウザーは見落としがちです。OSのDNS設定を確認して「正しいサーバーを向いている」と思っても、ブラウザーが独自にDoHで外部のサーバーに聞いていると、社内の名前が引けない、といったことが起きます。

自分がどのDNSサーバーを使っているかは、次のコマンドで確認できます（詳しくは第3回・第8回）。

# Windows
ipconfig /all

# Linux（systemd-resolved）
resolvectl status

# Linux（従来の設定ファイル）
cat /etc/resolv.conf

答えの出どころを確かめる

最後に、少しだけdigを使ってみます。同じ名前を引いても、キャッシュDNSに聞いた場合と、権威DNSに直接聞いた場合とで、応答の見え方が違います。

$ dig www.example.jp
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
www.example.jp.		259	IN	A	192.0.2.10

$ dig @ns1.example.jp www.example.jp +norec
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
www.example.jp.		300	IN	A	192.0.2.10

（出力は要所のみの抜粋です）

• 1つ目は、設定されたキャッシュDNSへの問い合わせです。flagsにaaがないので、キャッシュDNSが調べてきた答えだと分かります。
• 2つ目は、権威DNSに直接、再帰なし（+norec）で聞いた結果です。aa（Authoritative Answer）が立っています。
• TTLにも注目してください。権威DNSは設定値の300のまま、キャッシュDNSは残り時間（259）を返しています。

Windowsには標準でdigがないため、PowerShellのResolve-DnsNameを使います。

PS> Resolve-DnsName www.example.jp -NoRecursion -Server ns1.example.jp
Name              Type   TTL   Section    IPAddress
www.example.jp    A      300   Answer     192.0.2.10

Resolve-DnsNameではフラグは表示されませんが、TTLが設定値のままか、減っているかで同じように見分けられます。

なぜこれが大事かというと、出どころを取り違えると、切り分けの方向を誤るからです。

• 「権威DNSでは正しいのに、キャッシュDNSでは古い」→ キャッシュの問題
• 「権威DNSから間違っている」→ ゾーンの設定の問題

digの読み方は第8回で詳しく扱います。

考えてみよう

1. 自分のPCが使っているDNSサーバーを調べてください。それはキャッシュDNSですか、権威DNSですか。社内、VPN接続中、自宅で違いはありますか。
2. hostsファイルに何か書かれているサーバーはありませんか。書かれている理由と、消し忘れたときに起きることを説明できますか。
3. 「Webサイトが開けない」と言われたとき、名前解決の失敗とその後の通信の失敗を、どうやって見分けますか。

ヒント：この記事の「2段階の通信」、「身の回りのDNS」の確認コマンド、「答えの出どころを確かめる」のaaフラグとTTLが手がかりです。

まとめ

• DNSは、名前の管理を各組織に分担させた分散型のデータベース。hostsは今もDNSより先に参照される
• 通信は「名前解決」と「本来の通信」の2段階。障害時はまずどちらで失敗したかを見る
• 登場人物はスタブリゾルバー（依頼者）・キャッシュDNS（受付係）・権威DNS（台帳係）の3つ
• キャッシュDNSがルート→TLD→担当ゾーンと紹介をたどって答えを見つけ、キャッシュする
• 「DNSサーバー」と聞いたら、キャッシュか権威かを必ず確かめる

次回は、DNSの名前がどのような階層で管理され、委任によってどう分担されているかを扱います。

連載「DNS入門」全12回

1. DNSとは？名前解決の全体像と3つの登場人物（この記事）
2. ドメイン名の階層と委任
3. 名前解決の流れ
4. DNSメッセージとトランスポート
5. リソースレコード 前編
6. リソースレコード 後編
7. 権威DNSサーバーの運用
8. コマンドで調べる
9. DNSのセキュリティ
10. クラウド・社内環境のDNS
11. DNSトラブルシュート
12. DNS設計演習

• Microsoft SQL Server に関するお話
  • Microsoft SQL Server – Always On 高可用性 (SQL Server の導入)
  • Microsoft SQL Server – Always On 高可用性 (ファイアーウォールポリシー設定)
  • Microsoft SQL Server – Always On 高可用性 (Horizon ログ用データベースの作成)
  • Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ①)
  • Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ②)
  • Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ③)

Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ④)

SQL Server 認証の場合，SQL Server ノードで認証情報を持っていますのでフェイルオーバー後の認証や権限が無いため不具合が生じます．ですので，一度フェイルオーバーさせて権限割当てを行う必要があります．
フェイルオーバーさせないとセカンダリ側でデータベースの操作ができないため，フェイルオーバーで切り替えてあげる必要があるのです．
Windows 認証のデータベースの場合は本作業は不要です．

セカンダリサーバーの権限変更

フェイルオーバーさせたいデータベースが含まれている高可用性グループを選択，右クリックで「フェイルオーバー」をクリックします．

「高可用性グループのフェイルオーバー」ウィザードが起動しますので「次へ」をクリックします．

「新しいプライマリレプリカ」の選択でフェイルオーバーさせたいノードをクリックして「次へ」をクリックします．
画面では警告が出ていますが，これは AlwaysOn 高可用性グループを構成する際の設定で同期が非同期であるためです．
設定で同期を行うようにしている場合は表示されません．

「データ損失の可能性の確認」では，非同期の場合に損失が発生する可能性を警告しています．
今回はまだ未使用のデータベースである気にせずに「データ損失の可能性があるフェールオーバーを確認するには、ここをクリックします」にチェックを入れて「次へ」をクリックします．

もし，使用中のデータベースかつ，データ損失をなるべく抑えたい場合はこのウィザードを終了して AlwaysOn 高可用性グループの同期設定を変更してください．

「レプリカに接続」では先に選択したセカンダリノードに接続を行います．「接続」をクリックしてください．

「サーバーへの接続」ウィンドウが出て，セカンダリノードへの接続を促されますので認証情報を入力の上「接続」をクリックします．

セカンダリノードへの接続が完了したら「次へ」をクリックします．

「概要」では，フェイルオーバーの概要が表示されますので確認の上「完了」をクリックします．

フェイルオーバーが実行され「結果」にて状態が表示されます．
全て成功であれば無事フェイルオーバーが完了していますので「閉じる」をクリックします．

セカンダリノードの設定変更

セカンダリノードに接続して「データベース」より設定を変更したいデータベースを選択，右クリックでメニューを表示して「プロパティ」をクリックします．

「データベースのプロパティ」で「ファイル」をクリックします．
所有者が何もない状態が確認できますので「…」をクリックします．

「データベースの所有者の選択」でプライマリーノードで指定したユーザーと同じユーザー名を入力して「名前の確認」をクリックします．

ユーザーが検索出来たら，ユーザー名が [ユーザー名] と括られますので「OK」をクリックします．

所有者が設定されたことを確認して「OK」をクリックします．

セカンダリーノードのアカウントの修正

規定のデータベースを変更，アカウント状態を確認します．
本設定は必須ではありません．アカウント状態の確認だけの実施でも大丈夫です．

「セキュリティ」-「ログイン」より設定したいアカウントを選択，右クリックでメニューを表示して「プロパティ」をクリックします．

「全般」で「既定のデータベース」を変更します．

「ユーザーマッピング」でデータベースと権限を確認して，プライマリーノードと同一になっていることを確認します．
この際，プライマリーノードのデータベースは接続ができませんのであらかじめ設定状態を確認しておきましょう．

確認が完了したら「OK」で終了します．

a

プライマリーノードへのフェイルオーバー (フェイルバック)を実行

本項目も必須ではありませんが，プライマリーノードへ役割を戻します．
(日本人的にはプライマリーが優先というケースが多いため解説します)

操作はプライマリーノード，セカンダリーノードいずれでも構いません．今回はプライマリーノードで実施しています．
「AlwaysOn 高可用性グループ」-「可用性グループ」より，フェイルオーバーしたい高可用性グループを選択，右クリックして「フェールオーバー」をクリックします．

ウィザードが起動し「説明」が表示されますので「次へ」をクリックします．

「新しいプライマリレプリカの選択」でプライマリーにしたいノードを選択して「次へ」をクリックします．

「データ損失の可能性の確認」にて「データ損失の可能性があるフェールオーバーを確認するには、ここをクリックします」にチェックを入れて「次へ」をクリックします．

「概要」で内容を確認の上「完了」をクリックします．

フェイルオーバーが開始・完了し「結果」ですべて成功であれば正しくフェイルオーバーが完了しています．
「閉じる」をクリックしてウィザードを完了します．

以上で，SQL Server 認証でも AlwaysOn 高可用性グループを用いた冗長構成のデータベースを利用することができます．

次回は今回の AlwaysOn 高可用性グループで冗長したデータベースを利用して VMware Horizon のログデータベースの設定について解説します．

• Microsoft SQL Server に関するお話
  • Microsoft SQL Server – Always On 高可用性 (SQL Server の導入)
  • Microsoft SQL Server – Always On 高可用性 (ファイアーウォールポリシー設定)
  • Microsoft SQL Server – Always On 高可用性 (Horizon ログ用データベースの作成)
  • Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ①)
  • Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ②)
  • Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ③)

Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ③)

AlwaysOn 高可用性グループは SQL Server ノード間での通信が必要となります．AlwaysOn 高可用性グループを構成するウィザードの検証でもノード間通信ができるかの確認が行われますので，事前にファイアウォールポリシーで許可を設定する必要があります．

ですので，ファイアウォールポリシーの追加，AlwaysOn 高可用性グループの構成．という順番で作業を行います．

AlwaysOn 高可用性用のファイアウォールポリシーの追加

AlwaysOn 高可用性ではノード間で通信が発生します．そのため，Microsoft SQL Server で通常利用するポートである 1433/TCP の他，5022/TCP の通信を許可する必要があります．

「サーバーマネージャー」-「ローカルサーバー」より，Windows ファイアウォールをクリックします．

「Windows ファイアウォール」の「詳細設定」をクリックします．

以前「Microsoft SQL Server – Always On 高可用性 (ファイアーウォールポリシー設定)」で作成しているポリシーを選択，右クリックでメニューを表示して「プロパティ」をクリックします．

「プログラムおよびポート」タブをクリックし，「ローカルポート」に「5022」を追加して「適用」をクリックし，「OK」でウィンドウを閉じます．

以上で，AlwaysOn 高可用性で必要な通信を許可する設定は完了です．
今回は同じポリシーに追加をしていますが，もちろん別ポリシーとして作成しても大丈夫です．

AlwaysOn 高可用性の構成

スタートメニュー/プログラムの一覧より「SQL Server Management Studio」をクリックします．

「SQL Server Management Studio」より，SQL Server に接続します．AlwaysOn 高可用性を構成しますので管理者権限を持つアカウントでログインしてください．

「AlwaysOn 高可用性」-「高可用性グループ」を選択，右クリックでメニューを表示して「新しい高可用性グループ ウィザード」をクリックします．

「新しい可用性グループ」のウィザードが開始しますので「次へ」をクリックします．

「名前の指定」では可用性グループの名前を決定する必要があります．
今回，グループ名を「AG01」としました．AlwaysOn Group とか Available Group の略称です．
グループの入力が終わったら「次へ」をクリックします．

可用性グループの対象とするデータベースを選択して「次へ」をクリックします．
状態の所に「前提条件を満たしています」と表示されますが，バックアップが存在しない場合はここが「満たしていません」になりますので，その場合は「Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ②)」を参考にバックアップを取得してください．

「レプリカの設定」の「レプリカ」タブにて「レプリカの追加」をクリックします．

「サーバーへの接続」画面が表示されますので，AlwaysOn 高可用性に組み込む追加のノードを「サーバー名」に入力して「接続」を行ってください．

接続が完了するとこのように「サーバー インスタンス」に追加されます．

「エンドポイント」はどのポートを利用するかを設定する箇所です．規定では「5022/TCP」を利用します．ポートを変えたい場合は変更してください．
(もちろん，ファイアウォールポリシーも合わせて変更してください)

「バックアップの設定」はどのデータベースサーバーでバックアップを行うのかを指定します．
通常はデフォルトの「セカンダリ優先」で良いと思います．

詳細は「SQL Server Always On 可用性グループをバックアップする」を参照ください．

• セカンダリ優先
  オンラインのレプリカがプライマリ レプリカのみである場合を除き，セカンダリ レプリカでバックアップを実行することを指定します．
  オンラインのレプリカがプライマリ レプリカのみである場合は，プライマリ レプリカでバックアップを実行する必要があります．
• セカンダリのみ
  バックアップをプライマリ レプリカでは実行しないことを指定します．
  オンラインのレプリカがプライマリ レプリカだけの場合，バックアップは実行されません．
• プライマリ
  バックアップを常にプライマリ レプリカで実行することを指定します．
  このオプションは、差分バックアップの作成など，バックアップがセカンダリレプリカで実行されたときにはサポートされないバックアップ機能が必要な場合に役に立ちます．
• 任意のレプリカ
  バックアップを実行するレプリカを選択するときに，バックアップジョブが可用性レプリカの役割を無視するように指定します．

「リスナー」は AlwaysOn 高可用性グループで提供する接続ポイントを設定します．
後でリスナーを作成することもできますが，通常は合わせて設定します．

「高可用性グループのリスナーの作成」を選択して次の値を設定します．

• リスナーの DNS 名
  リスナーに付与する DNS 名です．FQDN で指定する際のホスト名になります．
• ポート
  リスナーが待ち受けるポートです．ここは通常の Microsoft SQL Server 同様に 1433 を設定する場合が多いと思います．
• ネットワークモード
  「静的IP」または「DHCP」が指定できます．通常は「静的IP」が多いと思います．

「ネットワークモード」で「静的IP」を選択した場合，IPアドレスを設定する必要がありますので「追加」をクリックします．

「IPアドレスの追加」ではサブネットの選択と，IPアドレスの入力を行います．
入力が終わったら「OK」をクリックして前の画面に戻ります．

入力したIPアドレスが正しいことを確認して「次へ」をクリックします．

「データ同期の選択」ではバックアップデータを選択する必要があります．
バックアップデータはレプリカの高可用性ノードでアクセスする必要がある為，共有ネットワークを指定してください．

バックアップの場所の指定が完了したら「次へ」をクリックします．

「検証」ですべての項目の検証結果が「成功」になったことを確認して「次へ」をクリックします．

「概要」では，ここまで設定した項目が一覧表示されますので内容を確認してください．
内容に問題が無ければ「完了」をクリックして AlwaysOn 高可用性グループの構成を開始します．

AlwaysOn 高可用性グループの構成が完了または失敗したら「結果」に表示されます．
結果がすべて「成功」であれば構成は完了となります．
「閉じる」でウィザードを終了します．

オブジェクトエクスプローラーで見える情報が最新の状態ではない場合が多いため SQL Server を選択，右クリックでメニューを表示して「最新の情報に更新」をクリックします．

「データベース」を開いて同期対象のデータベースの状態を確認します．
「AlwaysOn 高可用性」-「高可用性グループ」-「<作成したグループ>」-「高可用性レプリカ」および「高可用性データベース」を確認します．

以上で，AlwaysOn 高可用性グループの構成は完了しました．
今回の同期対象のデータベースは Windows 統合認証ではなく，SQL Server 認証です．このままだとフェイルオーバーした後認証に失敗しますので追加の設定が必要となります．
Windows 認証の場合はこのまま利用することが可能です．

次回は追加の設定について解説を行います．

今回はデータベースのバックアップと SMB 共有について解説します．

• Microsoft SQL Server に関するお話
  • Microsoft SQL Server – Always On 高可用性 (SQL Server の導入)
  • Microsoft SQL Server – Always On 高可用性 (ファイアーウォールポリシー設定)
  • Microsoft SQL Server – Always On 高可用性 (Horizon ログ用データベースの作成)
  • Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ①)
  • Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ②)
  • Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ③)

Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ②)

Always On 高可用性を構成するためには，最初に高可用性の対象とするデータベースのバックアップと そのバックアップデータを共有する必要があります．これが初回同期のベースイメージとなるようです．

今回は，バックアップ領域の作成，データベースバックアップの実施，バックアップデータの共有の流れで Step by Step で解説します．

データベースのバックアップ領域の作成

データベースバックアップ領域の作成を行います．SQL Server インストールの際規定でバックアップ用のフォルダーは作成されていますが，Always On 高可用性の場合は SMB 共有でのやり取りを行いますので別途用意したほうが扱いやすいです．

共有フォルダーを作成するため，作成する場所で右クリック「新規作成」-「フォルダー」をクリックします．

フォルダーの名前を変更します．今回は「SQL_BK」としました．

データベースのバックアップ

スタートメニュー/プログラムの一覧より「SQL Server Management Studio」をクリックします．

「SQL Server Management Studio」より，SQL Server に接続します．バックアップを行いますのでそれが可能なアカウントでログインしてください．

バックアップしたいデータベースを選択，右クリックでメニューを表示して「タスク」-「バックアップ」をクリックします．

「データベースのバックアップ」が開きます．
「全般」の「バックアップ先」で規定で設定されているパスを選択の上「削除」をクリックします．

先ほど作成したフォルダーを指定するため「追加」をクリックします．

「バックアップ先の選択」にて「ファイル名」を選択して「…」の参照ボタンをクリックします．

先ほど作成したフォルダーを選択の上ファイル名を入力して「OK」をクリックします．
ファイル名はなんでもよいです．今回は単純に日付にしましたが，日付_データベース名など分かりやすい名前が望ましいです．
ファイルの拡張子は「.bak」としましょう．

「バックアップ先の選択」に戻りますので「OK」をクリックします．

「データベースのバックアップ」ウィンドウに戻りますので「OK」をクリックします．
「OK」をクリックするとバックアップが開始されます．

バックアップが完了するとこのように完了した旨のウィンドウが表示されますので「OK」をクリックします．

バックアップ領域の SMB 共有とアクセス権設定

先ほど作成したフォルダー(データベースをバックアップしたフォルダー)を選択して右クリックでメニューを表示して「プロパティ」をクリックします．

プロパティ画面が開きますので「共有」タブをクリックして「詳細な共有」をクリックします．

「このフォルダーを共有する」にチェックを入れ，共有名を設定します．今回，共有名はフォルダー名と同じにしています．
また，アクセス許可を設定するため「アクセス許可」をクリックします．

まず，「Everyone」共有を選択して削除します．
このアカウントが有効だとフォルダー(SMB共有)に対しての読取り権限がついた状態になってしまいますので，明示的に権限を持つアカウントのみにするため削除することをお勧めします．

まずは管理者アカウント (管理者グループ) をアクセス許可として設定します．
アクセスを許可するアカウントを追加するため「追加」をクリックします．

アカウントの検索画面が表示されますので「Domain Admins」と入力して「名前の検索」をクリックします．

名前の検索が成功すると入力したユーザー名に下線が引かれます．
下線が引かれたことを確認して「OK」をクリックします．

続いて SQL Server サービスを動作させているアカウントを許可として追加します．
アクセスを許可するアカウントを追加するため「追加」をクリックします．

アカウントの検索画面が表示されますので「MSSQL」と入力して「名前の検索」をクリックします．
「MSSQL」のアカウント名は「Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ①)」で作成したアカウントです．

名前の検索が成功すると入力したユーザー名に下線が引かれます．
下線が引かれたことを確認して「OK」をクリックします．

追加したアカウントはそれぞれ「フルコントロール」の権限を付与しますので「フルコントロール」の「許可」にチェックを入れて「適用」をクリックします．

適用が完了したら「OK」をクリックしてアクセス許可の設定を完了します．

「詳細な共有」に戻りますので「OK」をクリックして設定を反映します．

プロパティ画面は「閉じる」で終了します．

これまでの記事で，Always On 高可用性のウィザードを実行する準備が整いました．

次回は，Always On 高可用性のウィザードを通じて実際に構成する方法について解説します．

• Microsoft SQL Server に関するお話
  • Microsoft SQL Server – Always On 高可用性 (SQL Server の導入)
  • Microsoft SQL Server – Always On 高可用性 (ファイアーウォールポリシー設定)
  • Microsoft SQL Server – Always On 高可用性 (Horizon ログ用データベースの作成)
  • Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ①)
  • Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ②)
  • Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ③)

Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ①)

Always On 高可用性を有効にするには，Microsoft SQL Server を動作させるアカウントをドメインアカウントに変更する．また，SQL Server の設定で Always On を利用可能にする2つの設定を行う必要があります．

以降，その設定を行う方法について解説します．

SQL Server サービス動作用の Active Directory アカウントの作成

「サーバーマネージャー」より「ツール」-「Active Directory ユーザーとコンピューター」をクリックします．

「Active Directory ユーザーとコンピューター」で，アカウントを作成したい OU または CN を選択して右クリックでメニューを表示し「新規作成」-「ユーザー」をクリックします．
今回はグループポリシー (GPO) の影響を与えたくないため Users コンテナを指定しています．

「新しいオブジェクト」でユーザー名などの必要事項を入力して「次へ」をクリックします．

パスワードを入力して「次へ」をクリックします．
また，サービス用アカウントのため「パスワードを無期限にする」を有効にしています．

「完了」をクリックしてアカウントの作成を完了します．

以上で Microsoft SQL Server のサービス用アカウントの作成は完了です．

SQL Server の Always On 利用可能設定と起動アカウント変更

SQL Server を動作させるアカウントを変更する方法はいくつかの方法がありますが，「Always On」の利用設定と共に行いますので「SQL Server 構成マネージャー」で変更する方法を紹介します．

アプリの一覧より「SQL Server 構成マネージャー」を開きます．

「SQL Server 構成マネージャー」が開いたら「SQL Server のサービス」より「SQL Server」を選択，右クリックでメニューを表示して「プロパティ」をクリックします．

「AlwaysOn 高可用性」タブで「Windows フェールオーバークラスター名」が WSFC のクラスター名であることを確認して「AlwaysOn 高可用性グループを有効にする」にチェックを入れて「適用」をクリックします．

Windows フェールオーバークラスターは事前に構成を完了させておく必要があります．まだの方は次の記事を参考にセットアップしてください．

• Windows Server Failover Cluster (WSFC) – フェイルオーバークラスターの説明
• Windows Server Failover Cluster (WSFC) – iSCSI ストレージのマウント
• Windows Server Failover Cluster (WSFC) – 機能の追加と初期セットアップ (1)
• Windows Server Failover Cluster (WSFC) – 機能の追加と初期セットアップ (2)

再起動を行う必要がある旨が表示されますので「OK」をクリックします．

続いて「ログオン」タブをクリックし，先ほど作成したアカウントに変更するため「このアカウント」を選択して「参照」をクリックします．

「ユーザー または グループの選択」が表示されます．Active Directory アカウントを検索するため「場所の指定」の「場所」をクリックします．

「場所」ウィンドウで「ディレクトリ全体」もしくは「Active Directory ドメイン」を選択して「OK」をクリックします．
複数ドメインが存在している場合，参照・検索範囲を絞るため「Active Directory ドメイン」を選択したほうがよいです．

ユーザーを指定するため「選択するオブジェクト名を入力してください」の入力欄に先ほど作成したアカウント名を入力して「名前の確認」をクリックします．

名前の検索が成功し，アカウント情報 (姓・名・プリンシパル名) に置き換われば成功ですので「OK」をクリックします．

アカウントに対応するパスワードを入力して「適用」をクリックします．

サービスの再起動を促すメッセージが表示されますので「はい」をクリックしてサービスを再起動します．

「OK」をクリックして変更を完了します．

以上で，Microsoft SQL Server のサービスアカウントの変更と Always On 高可用性を利用可能とする設定は完了となります．
同じ操作を Always On 高可用性を行う他のサーバーにも実施してください．

次回は，まずは Always On 高可用性の対象とするデータベースのバックアップとバックアップデータの共有が必要になりますのでその準備を解説します．

• Microsoft SQL Server に関するお話
  • Microsoft SQL Server – Always On 高可用性 (SQL Server の導入)
  • Microsoft SQL Server – Always On 高可用性 (ファイアーウォールポリシー設定)
  • Microsoft SQL Server – Always On 高可用性 (Horizon ログ用データベースの作成)
  • Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ①)
  • Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ②)
  • Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ③)

Microsoft SQL Server – Always On 高可用性 (Horizon ログ用データベースの作成)

プログラムの一覧より「SQL Server Management Studio」を選択，クリックします．

「SQL Server Management Studio」が開き，ログイン画面が表示されますので認証情報を入力して「接続」をクリックします．

Horizon ログデータベースアクセス用のユーザーを作成する

画面左側のオブジェクト エクスプローラーを展開して「セキュリティ」-「ログイン」を開き，右クリックでメニューを表示して「新しいログイン」をクリックします．

「ログイン – 新規作成」の「全般」でアカウント情報を入力します．
今回は VMware Horizon のログデータベース用ですので SQL Server 認証かつ，パスワードポリシーは無効にします．

• ログイン名
  SQL Server に接続する際のログイン名を指定します．
  Windows 認証の場合は Active Directory 上のアカウントを指定，SQL Server 認証の場合はログイン名を入力します．
• 認証方法
  • Windows 認証
    Active Directory 認証を行います．Microsoft は推奨していますが，一部製品では Windows 認証ができませんのでその場合は SQL Server 認証を用いる必要があります．
  • SQL Server 認証
    SQL Server 内部にアカウント情報を作成します．
    • パスワードポリシーを適用する
      パスワードの複雑性などのポリシーを適用します．この設定を無効にすると以降の設定はグレーアウトします．
    • パスワードの期限を適用する
      パスワードに期限を設けます．
    • ユーザーは次回ログイン時にパスワードを変更する
      初回ログイン時にパスワードの変更を強制させます．
• 規定のデータベース
  このユーザーが SQL Server に接続した際の規定のデータベースを指定します．
• 既定の言語
  このユーザーが SQL Server に接続した際の規定の言語を指定します．

「サーバーロール」は，このアカウントに割り当てるロールです．一般アカウントの場合は public で十分です．

各ロールについて以下簡単に解説します．詳細については「サーバー レベルのロール」を参照ください．

• bulkadmin
  BULK INSERT ステートメントを実行できます．
• dbcreator
  任意のデータベースを作成，変更，削除，および復元できます．
• diskadmin
  ディスク ファイルを管理できます．
• processadmin
  SQL Server のインスタンス内で実行中のプロセスを終了できます．
• public
  サーバー プリンシパルにセキュリティ保護可能なオブジェクトに対する特定のアクセス許可が与えられていないか，またはアクセス許可が拒否されている場合，そのユーザーは，そのオブジェクトに対して public に対して付与されているアクセス許可を継承します．
  すべてのユーザーがオブジェクトを使用できるようにする場合は，対象のオブジェクトに public 権限のみを割り当てます．
  public のメンバーシップを変更することはできません。
• securityadmin
  ログインとログインのプロパティを管理します．
  サーバー レベルのアクセス許可を GRANT，DENY，REVOKE することができます．
  securityadmin は，データベースレベルのアクセス許可を GRANT，DENY，REVOKE することもできます．
  また，securityadmin は SQL Server ログインのパスワードをリセットできます．
• serveradmin
  サーバー全体の構成オプションを変更したり，サーバーをシャットダウンしたりできます．
• setupadmin
  Transact-SQL ステートメントを使用して，リンク サーバーを追加および削除できます．
• sysadmin
  サーバーに対するすべての操作を実行できます．

「ユーザーマッピング」では特定のデータベースに対してのみ権限を変更したい場合に用いられます．
今回は後でデータベースを作成する際にオーナーとしてこのユーザーを指定することで設定を行います．

「状態」では，データベースエンジンに接続する権限やログインに対する権限を設定します．アカウントを無効化したいなどの場合に「拒否」や「無効」を設定します．

必要事項の入力が完了したら「OK」をクリックしてアカウントの作成を完了します．

Horizon ログ用データベースを作成する

「オブジェクトエクスプローラー」を展開し「データベース」を選択，右クリックでメニューを表示して「新しいデータベース」をクリックします．

「新しいデータベース」画面が開きますので「全般」タブでデータベース名などを設定します．

• データベース名
  作成するデータベースの名前を入力します．
• 所有者
  このデータベースの所有者を設定します．所有者に割り当てられたアカウントは DB Owner 権限が割り当てられ，このデータベースに対するすべての権限が付与されます．
• データベースファイル
  初期サイズや拡張ポリシーを設定します．ある程度容量が分かっていれば初期サイズを大きくするなどを行う事でパフォーマンスの改善を図ることができます．

所有者は「既定」となっていますので検索ボタンをクリックして先ほど作成したアカウントを割り当てます．

「データベース所有者の選択」画面で作成したアカウントを入力して「名前の確認」をクリックします．

名前の検索が成功したら「[HORIZON_LOG]」のように [] で括られますので，この状態になっていることを確認して「OK」をクリックします．

所有者が変更されたことを確認します．

オプションでは，データベースのオプションを設定することができます．

• 照合順序
  データを並べる際に大文字・小文字を意識するのかなどのポリシーを設定します．
  照合順序についての詳細な解説は「照合順序と Unicode のサポート」を参照ください．
  <規定> の場合は SQL Server をインストールした際に設定した照合順序である「Japanese_CI_AS」が選択されます．この場合は次のように判断されます．
  • 大文字/小文字の区別を行わない
  • アクセントの区別を行う
  • ひらがなとカタカナの区別を行わない
  • 全角/半角の区別を行わない
• 復旧モデル
  復旧モデルは，トランザクションをログに記録する方法，トランザクション ログのバックアップを必須 (および可能) にするかどうか，利用できる復元操作の種類などを制御するデータベースの設定です．
  詳細については「復旧モデル (SQL Server)」を参照ください．
  • 完全
    データ ファイルの消失や損傷によって作業が失われることはありません．
    アプリケーションエラーやユーザーエラーの発生前など，任意の時点に復旧できます．
  • 一括ログ
    完全復旧モデルを補完するためのもので，パフォーマンスに優れた一括コピー操作を実行できます．
  • 単純
    トランザクションログを保持しないため，障害時はデータ損失が起こり得ます．また Always On 高可用性は利用できません．
• 互換性レベル
  SQL コマンドや機能の互換性のレベルを設定します．過去のバージョンに最適化されたシステムの場合はバージョンを下げる必要がある場合があります．

Always On 高可用性による冗長化を考えている場合は復旧モデルは「完全」または「一括ログ」である必要があります．今回は「完全」を選択します．

「ファイルグループ」はデータベースを異なるディスクに分散配置したい場合などに利用されます．
詳細については「データベース ファイルとファイル グループ」を参照ください．
今回は何もせずに「OK」でデータベースを作成します．

アカウントの既定のデータベースの修正

アカウントの作成，データベースの作成が完了しましたので，作成済みアカウントのプロパティを修正して規定のデータベースを変更します．

作成したアカウントを選択，右クリックでメニューを表示して「プロパティ」をクリックします．

「全般」で「既定のデータベース」を先ほど作成したデータベースに変更します．

「ユーザーマッピング」をクリックすると，各データベースに対する権限が表示されます．
先ほどのデータベースの作成で所有者をこのアカウントにしていますので dbo/db_owner (Database Owner) の権限が付与されています．

この状態を確認して「OK」でプロパティ画面を終了します．

以上で VMware Horizon 用のログデータベースの作成は完了です．
SQL Server の冗長化を行わない場合はこのまま Horizon Admin 画面からデータベースの設定を行う事が可能ですが，今回は Always On 高可用性による冗長化の構成を取りますので次回 Always On 高可用性の設定について解説を行います．

• Microsoft SQL Server に関するお話
  • Microsoft SQL Server – Always On 高可用性 (SQL Server の導入)
  • Microsoft SQL Server – Always On 高可用性 (ファイアーウォールポリシー設定)
  • Microsoft SQL Server – Always On 高可用性 (Horizon ログ用データベースの作成)
  • Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ①)
  • Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ②)
  • Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ③)

Microsoft SQL Server – Always On 高可用性 (ファイアーウォールポリシー設定)

「サーバーマネージャー」-「ローカルサーバー」へアクセスし，「Windows ファイアウォール」のリンクをクリックします．

「詳細設定」をクリックします．

「受信の規則」を選択，右クリックでメニューを表示し「新しい規則」をクリックします．

「新規の受信の規則ウィザード」が開始されます．
「規則の種類」にて「ポート」を選択して「次へ」をクリックします．

「プロトコルおよびポート」にて以下のように設定して「次へ」をクリックします．

• TCP と UDP のどちらにこの規則を適用しますか
  TCP
• すべてのローカル ポートと特定のローカル ポートのどちらを対象にこの規則を適用するか選択してください
  特定のローカルポート: 1433

「操作」にて「接続を許可する」を選択して「次へ」をクリックします．

「プロファイル」にてこのポリシーをどこに適用するかを選択できます．
全てにチェックを付けて「次へ」をクリックします．

• ドメイン
  ドメインに参加しており，インターフェイスにドメインプロファイルが適用されている場合に利用されます．
• プライベート
  ドメインに参加しておらず，インターフェイスがプライベートプロファイルを適用している場合に利用されます．
• パブリック
  ドメインに参加しておらず，インターフェイスがパブリックプロファイルを適用している場合に利用されます．

「名前」ではわかりやすい名前を入力して「完了」をクリックします．

「ウィザード」が終了し，規則の一覧に作成したポリシーが表示されることを確認します．

以上で，外部のクライアントが SQL Server に接続する準備が整いました．
Always On 高可用性を利用しない場合は，前回の記事「Microsoft SQL Server – Always On 高可用性 (SQL Server の導入)」と今回の記事をもって SQL Server を外部のクライアントから接続して利用することが可能です．
Always On 高可用性を利用する場合は少し足りません．この点については Always On 高可用性を設定する際に追加設定を行う形で解説します．
また，Always On を想定している場合，この設定を全ての SQL Server で実施しておく必要がありますのでご認識ください．

• Microsoft SQL Server に関するお話
  • Microsoft SQL Server – Always On 高可用性 (SQL Server の導入)
  • Microsoft SQL Server – Always On 高可用性 (ファイアーウォールポリシー設定)
  • Microsoft SQL Server – Always On 高可用性 (Horizon ログ用データベースの作成)
  • Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ①)
  • Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ②)
  • Microsoft SQL Server – Always On 高可用性 (Always On 高可用性の構成 ③)

Microsoft SQL Server – Always On 高可用性 (SQL Server の導入)

Always On による冗長化は，Microsoft SQL Server 2008 ～ 2012 までは Enterprise 以上，2014 からは Standard で構成が可能です．

前提となる SQL Server は特に複雑な導入は不要でただ普通にインストールを行えば大丈夫です．

Microsoft SQL Server の導入

SQL Server の CD-ROM を挿入または ISO イメージのマウントを行い，エクスプローラーよりダブルクリックで開くと「SQL Server インストールセンター」が実行されます．

「SQL Server インストールセンター」より「インストール」をクリックします．

「SQL Server の新規スタンドアロンインストールを実行するか、既存のインストールに機能を追加します」をクリックするとインストーラーが開始されます．

一番最初に必要に応じてセットアップサポートファイルのインストールが行われます．「詳細の表示」をクリックすると次のように一覧が表示されます．
全て成功していることを確認して「OK」をクリックします．

「プロダクト キー」でプロダクトキーを入力して「次へ」をクリックします．

「ライセンス条項」では条項を確認の上「ライセンスに同意します」にチェックを行います．
また，必要に応じて「機能の使用状況データを Microsoft に送信します」にチェックを入れて「次へ」をクリックします．

「製品の更新プログラム」ではインストールに合わせて更新プログラムを導入することができます．
通常は「SQL Server 製品の更新プログラムを含める」にチェックを入れたままで良いと思います．
「次へ」をクリックします．

「セットアップ サポート ルール」ではインストール，セットアップに必要な前提条件の確認が行われます．基本は全て合格している必要があります．
今回は「Windows ファイアウォール」のみ警告が出ていますが，導入後にファイアウォールポリシーを作成することで対応が可能ですのでこのまま「次へ」をクリックします．

「セットアップロール」では「SQL Server 機能のインストール」を選択して「次へ」をクリックします．

「機能の提供」ではまずは必要最低限の機能を導入します．今回選択する機能は以下のとおりです．

• データベース エンジン サービス
• 管理ツール – 基本
• 管理ツール – 完全

最低限は上記3つとなります．必要な機能を選択して「次へ」をクリックします．

「インストール ルール」ではインストールが成功するか確認が行われます．全て合格した事を確認して「次へ」をクリックします．

「インスタンスの構成」ではデータベースインスタンスを決定します．
デフォルトでは「既定のインスタンス」です．今回は「既定のインスタンス」を選択しています．

また，インスタンス ルート ディレクトリは，データベースインスタンスを保存する場所を指定できます．
今回の構成ではデータベース用に別ディスクを搭載しているため，プログラムは「C ドライブ」，データベースは「E ドライブ」とするように構成しています．

設定が完了したら「次へ」をクリックします．

「必要なディスク領域」ではプログラムおよびデータベースインスタンスとして必要な容量が表示されます．確認の上「次へ」をクリックします．

「サーバーの構成」ではサービスアカウント，照合順序を設定します．
今後構成する Always On 高可用性の場合，ドメインアカウントで実行する必要がありますが，後ほど変更が可能ですのでここはデフォルトのままとします．

照合順序は既定の照合順序の指定になります．データベース毎に変更も可能ですのでデフォルトのままで大丈夫ですので，そのまま「次へ」をクリックします．

「データベースエンジンの構成」にて管理者アカウントの設定などを行います．

「サーバーの構成」では認証モードを指定できます．

• Windows 認証モード
  Active Directory による認証のみをサポートするモードです．Microsoft はこちらを推奨しています
• 混合モード
  Active Directory による認証および SQL Server 自身でアカウント管理を行った認証の両方をサポートしています．

VMware 製品で利用する場合，Active Directory と連携出来ない機器からの認証に不都合がある為，混合モードで導入を行います．
SQL Server システム管理者 (sa) のパスワードを設定，また，SQL Server 管理者の指定でドメイン管理者 (lab\Administrator) を追加しています．

「データディレクトリ」は各々のデータの保存場所を指定します．
「インスタンスの構成」のインスタンスルートディレクトリで「E ドライブ」を指定していますので，全てのディレクトリが「E ドライブ」起点になっています．

通常は変更の必要はありませんが，例えばバックアップデータはさらに別のドライブに持たせたいなどの場合はここで修正してください．

「FILESTREAM」はデータベーステーブルに BLOB (バイナリーオブジェクト) を保存するのではなく，ファイルシステム上にファイルとして保存できるようにする機能です．
今回は利用予定はないのでそのままとしています．

3つの項目の設定が完了したら「次へ」をクリックします．

「エラー レポート」はエラーが発生した際のエラー情報を Microsoft またはレポートサーバーに送信する機能です．
レポートサーバーを構成していませんのでデフォルトの無効のまま「次へ」をクリックしています．

「インストール構成ルール」は今まで設定した内容を踏まえてインストールが成功可能かチェックが実施されます．
全て合格した事を確認して「次へ」をクリックします．

「インストールの準備完了」では，今まで設定項目で設定・指定した内容が記載されます．
内容を確認し，問題が無ければ「インストール」をクリックします．

インストールが実行され，完了すると次の画面が表示されます．
全て「成功」であることを確認し「閉じる」をクリックします．

「SQL Server インストールセンター」も閉じるボタンをクリックして終了しましょう．

以上で SQL Server のインストールが完了です．Always On 高可用性による冗長構成の場合，もう1台の SQL Server で同じようにインストールを行う必要があります．

次回は Always On 高可用性を構成する手順を解説します．

• Windows Server Failover Cluster (WSFC) に関するお話
  • Windows Server Failover Cluster (WSFC) – フェイルオーバークラスターの説明
  • Windows Server Failover Cluster (WSFC) – iSCSI ストレージのマウント
  • Windows Server Failover Cluster (WSFC) – 機能の追加と初期セットアップ (1)

Windows Server Failover Cluster (WSFC) – スケールアウトファイルサーバー (SOFS)

ファイルサーバーの冗長化の種類

「Windows Server Failover Cluster (WSFC) – ファイルサーバーの冗長化 (2)」でも説明していますがここでも改めて説明します．

Windows Server によるファイルサーバーの冗長化は2つの方法があります．
通常の WSFC を利用したアクティブ-スタンバイ方式とアクティブ-アクティブ方式の SMB スケールアウトファイルサーバーです．

アクティブ-スタンバイ方式のファイルサーバー冗長化

一般的なファイルサーバーの冗長化の方式です．アクティブ-スタンバイですので，ファイルサーバーアクセスはアクティブノードのみが処理を行います．
アクティブノードに障害が発生が発生したらスタンバイノードがアクティブノードとなり処理を引き継ぎます．

アクティブ-アクティブ方式の SMB スケールアウトファイルサーバー

Windows Server 2012 以降で利用が可能になったアクティブ-アクティブ方式のファイルサーバーです．通常時はアクティブノードすべてが処理を受け付けます．障害が発生したら残ったアクティブノードが引き続き処理を行います．

SMB スケールアウトは最大8ノードのアクティブノードを持つことができます．

2つの方式のうちどちらを選択すべきか

アクティブ-アクティブで利用可能であれば SMB スケールアウト方式にすべきと思えますが，利用できる機能に差がありますので，提供したいファイルサーバーの構成によって選択する必要があります．

SMB スケールアウトの場合，容量制限である「クォータ」が利用できませんので，グループポリシーである程度制御はできますが，フォルダーリダイレクトや移動ユーザープロファイルの置き場にする場合は注意が必要です．
また，NFS 共有を提供することはできません．
こういった差を確認のうえ，どちらの方式でファイルサーバーサービスを提供するか決定してください．

役割の構成 – スケールアウトファイルサーバーの追加

「フェイルオーバークラスターマネージャー」の「役割」を選択，右クリックでメニューを表示して「役割の構成」をクリックします．

ウィザードが起動しますので「次へ」をクリックします．

「役割の選択」で「ファイルサーバー」を選択して「次へ」をクリックします．

「ファイルサーバーの種類」で「アプリケーションデータ用のスケールアウトファイルサーバー」を選択して「次へ」をクリックします．

「クライアントアクセスポイント」にてファイルサーバー名を入力して「次へ」をクリックします．

「確認」で設定内容を確認して「次へ」をクリックします．

正しく構成されたことを確認して「完了」をクリックします．

以上でスケールアウトファイルサーバーの役割の構成が完了しました．
今時点では役割だけが設定されているだけの状態ですので，続いてディスクの構成へ進みます．

CSV (クラスター共有ボリューム) のボリュームの準備

「コンピューターの管理」-「ディスクの管理」より，スケールアウトファイルサーバー用のディスクを選択，右クリックでメニューを表示して「オンライン」をクリックします．

なお，ストレージの接続は iSCSI で行っています．iSCSI ストレージのマウントは「Windows Server Failover Cluster (WSFC) – iSCSI ストレージのマウント」を参照ください．

オンラインにしたディスクを再度選択，右クリックでメニューを表示して「ディスクの初期化」をクリックします．

ディスクの初期化画面が表示されますので「OK」をクリックします．
2TB を超えるボリュームもしくは今後拡張して超える可能性がある場合は GPT パーティションを選択してください．

スケールアウトファイルサーバー用のボリュームはベーシックディスクである必要があります．
この手順だとベーシックディスクのはずですが，ここで確認をしておいてください．

続いて「未割当て」の所を右クリックでメニューを表示して「新しいシンプルボリューム」をクリックします．

ウィザードが起動しますので「次へ」をクリックします．

作成するボリュームサイズを入力して「次へ」をクリックします．変更しない場合は全ての領域を選択した事になります．

ここで注意があります．スケールアウトファイルサーバーはCSV (クラスター共有ボリューム) としてWSFC ノードの「C:\ClusterStorage」以下にボリュームをマウントします．
したがって「ドライブ文字またはドライブパスを割り当てない」を選択して「次へ」をクリックします．

スケールアウトファイルサーバーは NTFS でフォーマットされている必要があります．
ファイルシステムが「NTFS」であることを確認してください．
その他の値は任意です．指定が終わったら「次へ」をクリックします．

フォーマットが完了したら「完了」でウィザードを終了します．

ファイルシステムが作成されたこと，ドライブ文字やパスがないことを確認してください．

CSV (クラスター共有ボリューム) の追加

CSV (クラスター共有ボリューム) を登録するため，「フェイルオーバークラスターマネージャー」の「記憶域」-「ディスク」を右クリックでメニューを表示し「ディスクの追加」をクリックします．

クラスターディスクとして登録可能なディスクが表示されます．先ほどフォーマットしたディスクかどうかディスク情報や容量で判断してください．
登録するディスクを選択して「OK」をクリックします．

ディスクの一覧に登録されたことを確認したら，該当ディスクを選択，右クリックでメニューを表示して「クラスター共有ボリュームへの追加」をクリックします．

適用先が「クラスターの共有ボリューム」に変化したこと，また，画面下部よりマウント先が「C:\ClusterStorage\Volume{x}」としてマウントされたことを確認します．

エクスプローラーでもマウントされたか確認しましょう．

以上で，CSV (クラスター共有ボリューム) としての登録が完了しました．
続いて，ファイル共有の追加へと進みます．

ファイル共有の追加

「フェイルオーバークラスターマネージャー」の「役割」をクリックし，スケールアウトファイルサーバーの役割を選択，右クリックでメニューを表示し「ファイル共有の追加」をクリックします．

「この共有のプロファイルを選択」にて「SMB共有 – アプリケーション」を選択して「次へ」をクリックします．

共有の方法として今回は「ボリュームで選択」を利用します．
「ボリュームで選択」は指定したボリュームに「Shares」というフォルダーを作成，その下に共有名のフォルダーを作成する方法です．
CSV (クラスター共有ボリューム) が選択されていることを確認して「次へ」をクリックします．

共有名を入力して「次へ」をクリックします．
この際，共有するローカルパスおよび共有するリモートパスを確認して予定の共有パスかどうか確認をしておきましょう．

「他の設定」にて暗号化を行うかどうかを選択します．今回はチェックをつけずに「次へ」をクリックします．
なお，「SMB共有 – アプリケーション」の場合他のオプションは固定になります．

アクセス許可の設定をここでカスタマイズする場合は「アクセス許可をカスタマイズする」をクリックしてアクセス許可設定を行ってください．
今回は何もせずに「次へ」をクリックします．

作成する内容を確認して「作成」をクリックします．

正常に作成されたことを確認して「閉じる」をクリックします．

ファイルサーバーアクセスで動作確認

他のコンピューターより，ファイルサーバーへのアクセスができること，作成した共有が表示されることを確認しましょう．

DNS サーバーのレコードを確認すると，スケールアウトファイルサーバーはファイルサーバー名のレコードがノード数分存在することが確認できます．

クライアントより共有の下にフォルダーを作成してみます．

1台目のノードで作成されたフォルダーが確認できます．

2台目のノードでも作成されたフォルダーが確認できます．
2台で同時にアクセスできること，アクティブ – アクティブ で動作していることが分かったかと思います．

障害時のファイルサーバーアクセスの確認

クライアントより ping でアクセス先を確認してみます．ping だと1台目のノードに接続していることが確認できました．

1台目のノードを「パワーオフ」で障害状態を発生させます．

クライアントからアクセスを行うと最初無応答状態になりますが，ちょっと待つとアクセスできるようになることが確認できます．
この状態は，2台目のノードを利用したアクセスが行われていることになります．

テストとしてフォルダーを作成してみます．

2台目のノードで作成されたフォルダーを確認することができます．