どちらも、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設計演習

というのも、Proxmox VE / VMware / Nutanix は、同じ“仮想化”でも 守備範囲と思想（どこまでを一つにまとめるか） が違うからなんですよね。

この記事ではまず、Proxmox VEの概要と特徴を押さえた上で、
VMware vSphere / VCF（VMware Cloud Foundation）、Nutanixと比較しながら「何がどう違うのか」を整理します。

Proxmox VEの概要：仮想化に必要なものが“最初からひと通り入ってる”

Proxmox VE（Proxmox Virtual Environment） は、ひと言でいうと

• 仮想マシン（VM）
• コンテナ
• ストレージ
• ネットワーク
• クラスタ管理・HA
• バックアップ

みたいな、仮想化運用で必要になりがちな機能を 一式まとめて提供してくれるプラットフォームです。
ベースはDebian系Linuxで、管理は基本 Web UI が中心です。

まず押さえたい：Proxmoxは「VM」と「コンテナ」を同じ画面で扱える

Proxmox VEの分かりやすい特徴がここです。

VM（KVM）：OSごと分けたいときの“本命”

KVMで動くVMは、WindowsもLinuxも普通に載せられます。

たとえば…

• Active Directory / Windows Server
• 既存サーバを“そのまま移して”検証したい
• OSごと分離したい（独立性重視）

こういう用途はVMが向きます。

コンテナ（LXC）：軽くて速い“便利枠”

LXCコンテナは、VMより軽く、起動が速いのが強みです。
ただし同一カーネル上で動く仕組みなので、用途は選びます。

たとえば…

• 監視、ログ、バッチ、軽量なLinuxサービス
• すぐ作ってすぐ壊せる検証環境
• 台数を増やしてもリソースを節約したい

「VMほど重くしたくない」場面で刺さります。

Proxmox VEの特徴：運用目線で嬉しいポイント

1) Web UIが強い（まず“全体が見える”）

Proxmoxはブラウザで管理画面に入り、そこから

• VM/コンテナ作成
• CPU/メモリ/ディスク変更
• スナップショット
• バックアップ設定
• ネットワーク/ストレージ設定

など、運用で触る項目がだいたい揃っています。

CLI派でも、UIで俯瞰できるのは普通に便利です。

2) クラスタ化しやすい（最初は1台→後で増やせる）

最初は単体で始めて、後からノードを増やしてクラスタにする運用がしやすいです。

• ノード追加
• VM移動（マイグレーション）
• HA（高可用性）構成

「今は小さく、将来は冗長化したい」みたいな流れに乗せやすいのは大きいです。

3) バックアップが“標準の導線”として用意されている

仮想化って、作るのは簡単でも バックアップと復旧が弱いと運用で詰みます。
Proxmoxはバックアップ設定の導線が分かりやすく、定期実行も組みやすいです。

さらに本格運用なら Proxmox Backup Server（PBS） を組み合わせて、世代管理や効率化まで視野に入れられます。

4) ストレージの選択肢が広い（ただし“設計責任”は増える）

Proxmoxは選択肢が多いです。

• ローカルディスク
• NFS / iSCSI
• ZFS
• Ceph（分散ストレージ）

この自由度は魅力なんですが、裏返すと「設計を間違えると地獄」になりやすい領域でもあります。
この話は別記事で丁寧にやる価値があります。

5) ネットワークが“現実的に一通りできる”

Linux bridge をベースに、

• VLANタグ（trunk運用）
• ルールベースのFW（ホスト/VM単位）

など、現場で必要になりがちなことは一通りこなせます。

ここから比較：vSphere、VCF、Nutanixは“同じ土俵”じゃない

比較で混乱しやすいので、まず前提を揃えます。

VMware vSphere：仮想化（ハイパーバイザ＋管理）の定番

「VMwareの仮想化」＝まずはこれ。
ESXi＋vCenter中心で、仮想化の王道です。

VMware VCF（VMware Cloud Foundation）：プライベートクラウドの“統合スイート”

VCFは、vSphereに加えて

• ストレージ（vSAN）
• ネットワーク/セキュリティ（NSX）
• ライフサイクル管理（LCM）

みたいな領域まで含めて「まとめて提供する」発想です。
要は 仮想化基盤というより“プライベートクラウドの完成形をパッケージ化” したイメージです。

Nutanix：HCI（ハイパーコンバージド）の“統合プラットフォーム”

Nutanixは、分散ストレージ（AOS）を核に、

• 仮想化（AHV）
• 統合管理（Prism）

をまとめて提供する HCIの代表格です。
“ストレージ込みで最初から型がある”のが強みです。

比較のポイント：Proxmoxは「統合型だけど自由度が高い」

Proxmoxも統合型ではあるんですが、VCFやNutanixほど「この型で完成」というより、

• 仮想化運用の土台機能は揃ってる
• ストレージや構成は要件に合わせて組める

という立ち位置です。

これがメリットにもデメリットにもなります。

機能軸でざっくり比較（ここだけ読んでもOK）

仮想化（VM/コンテナ）

• Proxmox：VM（KVM）＋コンテナ（LXC）を同一UIで運用
• VMware：VM中心（スイートで周辺も拡張）
• Nutanix：AHV中心でHCIとして統合

「VM＋軽量コンテナを同じ運用面で回したい」ならProxmoxは分かりやすいです。

管理（運用プレーン）

• Proxmox：統合Web UIで完結しやすい
• VCF：プライベートクラウド前提で“管理も仕組み化”
• Nutanix：Prismで統合管理

“運用を標準化して自動化したい”ほど、VCF/Nutanixの価値が出やすいです。

ストレージ（設計の自由度と難易度）

• Proxmox：ZFS/Ceph/NFS/iSCSI…選べる（自由度高い）
• VCF：vSAN/NSXなどスイートで型を作りやすい
• Nutanix：AOS中心でHCIの型がある

Proxmoxは自由度が高い分、設計・監視・障害切り分けは自分たちの責任になりやすいです。
逆にNutanixやVCFは“型”に乗せて運用品質を作りやすい印象です。

まとめ比較表（意思決定用）

じゃあ、どう選ぶ？（現実的な判断軸）

最後に、ざっくり指針を置いておきます。

• 「まず動かして学びたい／低コストで検証→そのまま運用したい」
  → Proxmoxがハマりやすい（VMとLXCを同じUIで回せるのが強い）
• 「既にVMwareが標準で、人・手順・監査・周辺が揃っている」
  → vSphere継続が合理的なことが多い（ただし契約や更改条件は要確認）
• 「ネットワーク/ストレージ/運用まで含めて、私設クラウドとして標準化したい」
  → VCFの狙いどころ（“仕組みとして”まとめる方向）
• 「HCIとして、とにかく運用を簡素化して拡張しやすくしたい」
  → Nutanixが強い（型に乗せやすい）

次回予告

次回は、Proxmox VEのインストール手順を実際の画面・設定項目ベースでまとめます。
ISOの入手からインストーラ起動、ディスク構成（ext4／ZFSの選び方）、管理用IP・DNS・ゲートウェイ設定、インストール後の初期設定（リポジトリ設定、更新、時刻同期、ストレージ追加、Bridge作成）まで、つまずきやすいポイントを押さえつつ“そのまま真似できる”形で解説する予定です。

本記事では，Horizon ログデータベースの設定方法，確認について解説します．

• VMware Horizon に関するお話
  • VMware Horizon – 接続サーバー (コネクションサーバー) のインストールと初期設定
  • VMware Horizon – 接続サーバー (レプリカサーバー) のインストール
  • VMware Hoirzon – フルクローンデスクトップの作成と公開 – Horizon Agent の導入
  • VMware Hoirzon – フルクローンデスクトップの作成と公開 (1)
  • VMware Hoirzon – フルクローンデスクトップの作成と公開 (2)

VMware Hoirzon – Horizon ログデータベースの設定

今までの記事で「Microsoft SQL Server – Always On 高可用性 (Horizon ログ用データベースの作成)」などで Always On 高可用性グループを用いたデータベースを作成しましたのでこのデータベースを利用する設定を行います．
冗長構成を行わない場合でも Horizon Administrator での設定は変わりません．

Horizon Administrator でデータベースを設定する

Horizon Administrator 管理者画面にアクセス，ログインを実施します．

ログインしたら「設定」-「イベント構成」をクリックします．

「イベント構成」に移動しますので「イベントデータベース」の「編集」をクリックします．

「イベントデータベースを編集」の画面で必要事項を入力します．

• データベースサーバ
  データベースサーバーの FQDN か IP アドレスを入力します．今回は AlwaysOn 高可用性グループのリスナー IP に対応した FQDN を入力しています．
• データベースタイプ
  Microsoft SQL Server か Oracle，PostgreSQL を利用できます．
• ポート
  ポート番号を入力します．デフォルトでは Microsoft SQL Server は 1433，Oracle は 1521，PostgreSQL は 5432 が利用されます．
• データベース名
  データベース名を入力します．
• ユーザー名
  ユーザー名を入力します．Microsoft SQL Server では Windows 統合認証を利用できないため，SQL Server 認証のアカウントを入力します．
• パスワード
  ユーザー名に対応するパスワードを入力します．
• テープブルのプリフィックス
  作成されるテーブルのカスタムプリフィックスを設定したい場合に利用します．
  通常は専用でデータベースを持つと思いますので空白で構いません．何かと共有したデータベースを利用せざるを得ない場合にカスタムプリフィックスを付与します．

入力を完了したら「OK」をクリックします．

「イベント構成」に戻りますので，入力された内容が反映されていることを確認します．

Management Studio でデータベーステーブルを確認する

「スタート」メニューをクリックし「SQL Server Management Studio」をクリックします．

Microsoft SQL Server に接続します．

「データベース」より，Horizon Log データベースを展開し，テーブルが作成されていることを確認します．

以上，ログデータベースの設定について解説しました．
次回以降は 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 高可用性の構成 ④)

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 高可用性のウィザードを通じて実際に構成する方法について解説します．

【資格取得】AWS Certified Solutions Architect – Associate に合格しました

勉強に使用した教材は一冊の書籍と CloudTechさんの Youtube 動画です．

AWS認定資格試験テキスト　AWS認定ソリューションアーキテクト – アソシエイト　改訂第3版 [ 佐々木 拓郎 ] 楽天で購入

AWS Certified Solutions Architect – Associate に関連する内容が全般的に押さえられており，かつ各セクションに練習問題があります．
練習問題を PDF で入手できますので試験勉強の仕上げも可能です．ただし… この PDF は印刷不可で配布されているのでその点は認識しておいてください．

この書籍を何度か一通り読んでいき，その後各セクションを読みつつセクションの終わりの練習問題を解く．と繰り返しました．
また，先に述べた通り CloudTech さんの動画も聞きながら移動するという形で勉強を行いました．
見るというより聞くがメインでした．

「【資格取得】Aws Cloud Practitioner に合格しました」では無料枠を利用して勉強しようかなぁ… と書いていたのですが，無料枠を使わずに座学だけで合格することができました．

ただし… 試験問題は練習問題や CloudTech の Youtube チャンネルの問題とも違っており合格の連絡が来るまでドキドキしました…

前提として，自分はある程度業務でオンプレ・クラウドのインフラに関わっているので何とか合格できましたが，自信がない方は「AWS 無料利用枠」がありますので，実際に触って覚えるのが一番だと思います．

「AWS Certified Solutions Architect – Professional」の資格取得を考えてはいますが，これはさすがに触って行かないと難しそうだな… と考えています．

以上，資格取得についての報告でした．

• 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 高可用性の設定について解説を行います．