2017年5月9日火曜日

Hyper-VまたはAzure上のドメインコントローラーでの時刻同期

以前、Hyper-V上のドメインコントローラーについて書きました(Hyper-V 仮想化環境での時刻同期)。

この時は「ドメインコントローラーについては、Hyper-Vを使ったホストとの同期を停止する」と紹介しています。根拠は、マイクロソフトの公開文書「仮想化ドメイン コントローラーの展開に関する考慮事項」です。

Microsoft Azureの仮想化基盤はHyper-Vなので、Azure上のドメインコントローラーについても同じことが言えるはずです。

しかし、Azureテクニカルサポート チームのブログ「Azure 仮想マシンの時刻同期の仕組み」では、ホスト同期を無効にする方法について触れつつも「基本的には、Azure に時刻同期を任せてしまう、という考えで、既定のままにしていただくことが便利です」とあります。

矛盾するようですが、以下のようなことではないかと想像します。

Hyper-V、つまりオンプレミス環境では複数の仮想化ホスト(物理マシン)の時刻同期がきちんと行われていない可能性があります。こうした状況でホスト同期を行うことはリスクが大きいため、ドメインコントローラー自身が持つNTP時刻同期を使う方が無難です。

しかし、Azure内にあるすべての物理マシンは時刻同期が正しく行われています。このような環境では、ホスト同期を優先した方がリスクが小さいと考えられます。

逆に言うと、すべてのHyper-Vホストが適切に時刻同期している環境であれば、ホスト同期を有効にしたままで問題ない(むしろ推奨される)と思われます。

2017年4月11日火曜日

Azure仮想マシン展開用のJSONファイル

Microsoft Azureの仮想マシンを一般化して再展開する場合は、JSON形式のフォーマットでパラメーターを与える必要があります。

このフォーマット、なかなか複雑なので苦労します。私が使っているものを公開しておきます。

なお、このファイルはマイクロソフトの安納さんのブログ記事「Azure Resource Manager で作成した仮想マシンをキャプチャーする」に掲載されたものを一部修正し、可用性セットの設定を追加したものです。

もっとも、現在は「管理ディスク(managed disk)」を使った仮想マシンであれば、GUIで簡単に取り込めるので、JSONファイルの出番もあまりないかもしれません。



{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",

    "parameters": {
      "osMasterImageUri": {
      "type": "string",
      "metadata": {
        "description": "マスターイメージのURI"
      }
    },
    "vmName": {
      "type": "string",
      "metadata": {
        "description": "仮想マシンの名前"
      }
    },
    "osType": {
      "type": "string",
      "allowedValues": [
        "Windows",
        "Linux"
      ],
      "defaultValue" :"Windows",
      "metadata": {
        "description": "OSのタイプ"
      }
    },
    "adminUserName": {
      "type": "string",
      "metadata": {
        "description": "管理者ユーザーID"
      }
    },
    "adminPassword": {
      "type": "securestring",
      "metadata": {
        "description": "管理者ユーザーIDのパスワード"
      }
    },
    "vmSize": {
      "type": "string",
      "allowedValues": [
        "Standard_D1",
        "Standard_D1_v2",
        "Standard_F1"
      ],
      "defaultValue" :"Standard_F1",
      "metadata": {
        "description": "仮想マシンのサイズ"
      }
    },
    "StorageAccountName": {
      "type": "string",
      "metadata": {
        "description": "ストレージアカウントの名前"
      }
    },
    "existingVirtualNetworkName": {
      "type": "string",
      "metadata": {
        "description": "仮想ネットワーク"
      }
    },
    "subnetName": {
      "type": "string",
      "metadata": {
        "description": "サブネット名"
      }
    },
    "availabilitySetName": {
      "type": "string",
      "metadata": {
        "description": "可用性セット名"
      }
    }
  },

  "variables": {
    "api-version": "2015-06-15",
    "location": "[resourceGroup().location]",
    "publicIPAddressType": "Dynamic",
    "vnetID": "[resourceId('Microsoft.Network/virtualNetworks', parameters('existingVirtualNetworkName'))]",
    "subnetRef": "[concat(variables('vnetID'),'/subnets/', parameters('subnetName'))]",
    "nicName": "[concat(parameters('vmName'),'-nic')]",
    "publicIPAddressName": "[concat(parameters('vmName'),'-pip')]",
    "osDiskVhdName": "[concat('http://',parameters('StorageAccountName'),'.blob.core.windows.net/vhds/',parameters('vmName'),'osDisk.vhd')]"
  },

  "resources": [
    {
      "apiVersion": "[variables('api-version')]",
      "type": "Microsoft.Network/publicIPAddresses",
      "name": "[variables('publicIPAddressName')]",
      "location": "[variables('location')]",
      "properties": {
        "publicIPAllocationMethod": "[variables('publicIPAddressType')]"
      }
    },
    {
      "apiVersion": "[variables('api-version')]",
      "type": "Microsoft.Network/networkInterfaces",
      "name": "[variables('nicName')]",
      "location": "[variables('location')]",
      "dependsOn": [ "[concat('Microsoft.Network/publicIPAddresses/', variables('publicIPAddressName'))]" ],
      "properties": {
        "ipConfigurations": [
          {
            "name": "ipconfig1",
            "properties": {
              "privateIPAllocationMethod": "Dynamic",
              "publicIPAddress": {
                "id": "[resourceId('Microsoft.Network/publicIPAddresses',variables('publicIPAddressName'))]"
              },
              "subnet": {
                "id": "[variables('subnetRef')]"
              }
            }
          }
        ]
     }
  },
  {
    "apiVersion": "[variables('api-version')]",
    "type": "Microsoft.Compute/virtualMachines",
    "name": "[parameters('vmName')]",
    "location": "[variables('location')]",
    "dependsOn": [
      "[concat('Microsoft.Network/networkInterfaces/', variables('nicName'))]"
    ],
    "properties": {
      "hardwareProfile": {
        "vmSize": "[parameters('vmSize')]"
      },
      "osProfile": {
        "computername": "[parameters('vmName')]",
        "adminUsername": "[parameters('adminUsername')]",
        "adminPassword": "[parameters('adminPassword')]"
      },
      "storageProfile": {
        "osDisk": {
          "name": "[concat(parameters('vmName'),'-osDisk')]",
          "osType": "[parameters('osType')]",
          "caching": "ReadWrite",
          "createOption": "FromImage",
          "image": {
            "uri": "[parameters('osMasterImageUri')]"
          },
          "vhd": {
            "uri": "[variables('osDiskVhdName')]"
          }
        }
      },
      "networkProfile": {
        "networkInterfaces": [
          {
            "id": "[resourceId('Microsoft.Network/networkInterfaces',variables('nicName'))]"
          }
        ]
      },
      "availabilitySet": {
           "id": "[resourceId('Microsoft.Compute/availabilitySets', parameters('availabilitySetName'))]"
      }
    }
  }
  ]
}

今さら聞けない! Active Directory入門

2017年4月10日(月)に「今さら聞けない! Active Directory入門」というタイトルで無料セミナーを行ないました。

スライドは「今さら聞けない! Windows Server 2016 Active Directoryドメインサービス入門」として公開しています。

私が初めてActive Directoryに触ったのが1997年ですから20年経ったことになります。

今でも基本的な構造は全く変わっていないのは、当初の設計が良かったからでしょう。

もっとも、1997年当時は今と違うこともたくさんあって、ドキュメントには「Windows NTでは、ローカルグループとグローバルグループが分かりにくかったので、Active Directoryでは単に『グループにする』とありましたが、実際にはユニバーサルグループが追加されて、さらに複雑になっています(しかし、分かりやすくはなりました)。

DSA
▲Windows NT 5.0ベータ1での管理画面

2017年4月7日金曜日

クラウドコンピューティングの定義: rapidly provisioned and released

訳あって、改めてクラウドコンピューティングの定義を調べています。

米国商務の国立標準技術研究所(NIST)の定義は、WordファイルだったのがPDFになっていました。

The NIST Definition of Cloud Computing

この翻訳はいくつかあるのですが、最も有名なものが情報処理推進機構(IPA)のものでしょう。

NISTによるクラウドコンピューティングの定義

クラウドコンピューティングは、共用の構成可能なコンピューティングリソース(ネットワーク、サー バー、ストレージ、アプリケーション、サービス)の集積に、どこからでも、簡便に、必要に応じて、ネットワーク経由でアクセスすることを可能とするモデルであり、最小限の利用手続きまたはサービスプロバイダとのやりとりで速やかに割当てられ提供されるものである。

以前読んだものを少し違う、と思って調べたらAgile Catさんによる別の翻訳もありました。

とても重要な NIST のクラウド定義:対訳

クラウド・コンピューティングとは、コンフィグレーションが可能なコンピューティング・リソース(ネットワーク/サーバー/ストレージ/アプリケーション/サービス)で構成される共有層への、オン・デマンドのネットワーク・アクセスを可能にするための、利便性の高いモデルのことだ。そして、それらのリソースは、最小の管理手順もしくは、サービス・プロバイダーとのやりとりにより、迅速に供給され、また、解消されるものとなる。

太字部分の原文はこうなっています。

rapidly provisioned and released

一般的な「release」の意味は「解放する」でしょう。スポーツフィッシングでよくある「catch and release」のreleaseです。

クラウドコンピューティングで「(利用者が)仮想マシンをリリースする」と言えば「仮想マシンを物理的な結びつきから解放する」「削除する」の意味になります。

一方で、releaseには「提供」の意味もあります。通常は「出版」の意味で使いますが、IT分野では「製品がリリースされる」のような使い方をします。

クラウドコンピューティングで「(クラウド事業者が)新しい仮想マシンをリリースする」と言えば「社内で準備していたものが、一般提供(社内だけのものから一般解放)された」となり、「高性能な仮想マシンを使う準備ができた」になります。

このように、誰が主体かによってまるで違う意味になってしまいます。

さて、本当はどうなんでしょうね。

クラウドでは「すぐに確保する」ことと同じくらい「すぐに(追加費用なしで)解放する」ことが大事なので、「解消」説を採用したいと思います。

そういえば、CRMを提供しているクラウドサービスの会社「Salesforce」の方が、何かの講演で言ってました。

Salesforceの顧客満足度はとても高い。
なぜなら「不満のある人はすぐに解約する」。

半ば冗談のようでしたが、これは非常に大事なことだと思います。

DSC00409
▲我が家のSurface RT、不要になったけどなかなか捨てられない

2017年3月31日金曜日

今さら聞けない! Microsoft Azure 仮想マシン入門

2017年3月30日(木)「今さら聞けない! Microsoft Azure 仮想マシン入門」というタイトルで無料セミナーを開催しました。

内容は、「管理ディスク(Managed Disk)」を使った仮想マシン展開とテンプレート作成の方法で、比較的新しいお話ができたのではないかと思います。

クラシックモデルでは容易だった仮想マシンイメージの作成が、リソースマネージャーになるとJSONファイルを扱ったり、リソースエクスプローラーを使ったり、結構面倒だったのですが、管理ディスクを使うことでクラシックモデル並みに簡単になりました。

管理ディスクの本来の意味は、「ストレージアカウントの管理からの開放」ですが、簡単にテンプレートが作れるようになったことも大きいと思います。

当日使用したスライドを公開してもらったので参考にしてください。

スライドシェア: 今さら聞けない! Microsoft Azure 仮想マシン入門

02-DSC03764 (1024x684)
▲写真と本文は関係ありません

2017年3月1日水曜日

Microsoft Azureのポイント対サイトVPNの設定

Microsoft Azureのポイント対サイトVPNの設定をGUIだけで行うことはできない、と思ってたんですができました。前からできたのか、最近できるようになったのかは未確認です。

これで「Microsoft AzureによるITインフラの拡張」でPowerShellが必要なのは、仮想マシンを一般化する部分だけになっているはずです。

やり方は以下の画面で値を入力し、[save]をクリックするだけです。

P2S-1
▲上の枠がアドレスプール、下の枠がルート証明書の設定

 

●アドレスプール

VPNインターフェース用のIPアドレス範囲です。サブネットマスクは24ビット以上が必要です。

ここでは、192.168.1.0/24を指定しています。

 

●ルート証明書

BASE64形式のルート証明書の本体(BEGIN/ENDを含まない範囲)を貼り付けます。ファイルを参照する機能はありません。

ここでは2つ目のルート証明書として指定しています。

1行しか枠がないところに、これだけの内容を貼り付けるのは不自然ですね。

2017-03-01 (8)
▲選択した部分をクリップボード経由で貼り付ける

2016年12月15日木曜日

社内の複数拠点からMicrosoft AzureにVPN接続する

Microsoft Azureで「社内の複数の拠点からVPNを張ってAzureのリソースを使いたい」と言われることがあります。

image

従来は、簡単な作業でなかったのですが、リソースマネージャーモデルであれば、以下のようにGUIだけで構成できます。リソースマネージャーでもVPNゲートウェイは1台しか作れませんが、複数の接続を簡単に追加できるからです。

まず拠点単位でローカルネットワークゲートウェイを構成します。ローカルネットワークゲートウェイは、オンプレミスのVPNルーターの情報を保存したものです。

次に、ローカルネットワークゲートウェイを使って、接続を追加します。

image

ここまでで、Azureと拠点A、Aureと拠点Bの接続が完了します。

マイクロソフトが提供するオンプレミス側VPNゲートウェイの構成スクリプトは、Azureの仮想ネットワークとローカルネットワークの範囲しかルーティングしないため、拠点Aと拠点Bの接続は構成されません。

これは、既存のルーティング情報に影響を与えないためです。そのため、Azureとの接続前から拠点Aと拠点Bが接続できている場合はそのまま使い続けることが可能です。

ただし、AzureのVPNゲートウェイ自体はローカルネットワークゲートウェイの情報を使ったルーティングが可能なので、オンプレミス側VPNゲートウェイで必要なルーティング情報を与えてやれば、拠点Aと拠点Bの接続が可能です。

以上の内容を図にしました。

image

同様に、ローカルネットワークゲートウェイのネットワーク範囲を追加すれば、オンプレミス側のネットワークも拡張できます。

なお、インターネット回線を通るため、拠点Aと拠点Bの通信にはそこそこ大きな遅延が発生します。

実際に、東京のトレーニングセンター内で仮想的に2つの拠点を作り、東日本のデータセンターにVPNゲートウェイを作って、拠点Aから拠点Bにpingを飛ばしたところ、10ミリ秒から25ミリ秒の遅延が発生しました(オンプレミスのルーターはWindows Server 2012 R2仮想マシン)。

連続して通信を行っても、遅延にはかなりばらつきがありました。決して品質が高いとはいえないのですが、インターネットにさえつながればどこからでも接続できるので、便利な状況もあるでしょう。

image