2019年10月26日土曜日

【Azure】Azureポータルのハブメニューが消えた?

ひと目でわかるAzure「基本から学ぶサーバー&ネットワーク構築」第3版が無事出版されました。

ひと目でわかるAzure基本から学ぶサーバー&ネットワーク構築第3版

前著から100ページ増加していますが、値段は200円アップにとどめています。

左から、初版、改訂新版、第三版です。第3版でだいぶ厚くなっていることが分かります。

クラシックモデルの内容をだいぶ削ったので、ここまで厚くなるとは思いませんでした。そもそも、そんなに加筆したつもりはないのですが。

例によって、校正中に機能が変わったり、画面が変わったりして、多少困ったこともあったんですが、大きな変化はなくてよかったと思います。

が、最近、Azureポータルの操作がちょっと変わりました。

左端のメニュー(ハブメニュー)がなくなりました。


3本ラインのハンバーガーボタン(本来は「引き出し」のアイコンらしい) を押すと出てきます。

従来のハブメニューは、正直ちょっと邪魔だったのでよく縮小してました。前著「改訂新版」でも、ハブメニューを縮小した画面ショットを多用しています。今回はきちんと表示しているのですが、これだったら隠しても良かったですね。


2019年8月2日金曜日

【Azure】Azureサイトリカバリーで可能な操作

「Microsoft Azureによる災害復旧手法」のテキストで、少しわかりにくいところがあったので補足します。

詳細は、マイクロソフトの公式情報「Hyper-V から Azure へのディザスター リカバリー アーキテクチャ」をご覧ください。


いつでも実行可能な操作

以下の作業はいつでも実行可能です。

  • 移行の完了…現在の状態を保存し、複製を正常に終了(フェールオーバー中の仮想マシンは残る)
  • レプリケーションの無効化…複製をなかったことにする(フェールオーバー中の仮想マシンは残る)


Hyper-V対Azure

Hyper-V対Azureの複製の場合、利用可能な操作は以下の通りです。

●平常時(Hyper-Vで実行)

  • 計画されたフェールオーバー
  • フェールオーバー
  • テストフェールオーバー

●テストフェールオーバー中(両方で実行)

  • テストフェールオーバーのクリーンアップ

●計画されたフェールオーバー(Azureでの実行に切り替え)

  • 復旧ポイントの変更
  • コミット(復旧ポイントの確定)

●計画されたフェールオーバー後のコミット後(Azureで実行中)

  • 計画されたフェールオーバー(つまりフェールバック)

●フェールバック中

  • コミット(フェールバックが確定するが、Azure上の複製に対して構成変更できないなどの制限がある)

●フェールバック中のコミット後

  • レプリケーションの反転(複製を含め、すべてが平常時の状態に戻る)

Azure対Azureの場合

オプション演習のAzure対Azureの複製の場合、利用可能な操作は以下の通りです。

●平常時

    • フェールオーバー
    • テストフェールオーバー

    ●テストフェールオーバー中

    • テストフェールオーバーのクリーンアップ

    ●フェールオーバー中

    • 復旧ポイントの変更
    • コミット→復旧ポイントの確定

    ●フェールオーバーからのコミット後

    • 再保護→反転した複製の開始→平常時へ移行

    Azure対Azureは、両サイトが対等の関係なので「フェールバック」という概念はないようです。


    【追記】

    フェールバック中、コミットした段階で複製は始まります。ただし、反転するまではフェールオーバーができません。フェールバック後の障害に備えるには、必ず反転する必要があります。

    2019年7月28日日曜日

    「クラウド市場シェアナンバーワン」に意味はない

    「AWSが世界のクラウドサービス市場で首位陥落、マイクロソフトが逆転」というニュースが入ってきて、正直ちょっとあわてました。

    AWSがクラウド業界のリーディングカンパニーであることは間違いなく、それを追うのがマイクロソフトという構図は変わっていません。また、市場シェアはAWSのざっと半分がAzureというのが一般的な見解です(調査会社によっては4倍程度まで開きます)。

    「AWS vs. マイクロソフト」つまり、SaaSを含む全クラウドの売り上げを集計すると、僅差でマイクロソフトが勝ったということです。逆にいうと、ほとんどSaaSを持たないAWSが、僅差で2位というのはいかにAWSが支持されているかの証拠でもあります。

    SaaS (Software as a Service) はクラウドの一種ではありますが、利用者の意識はちょっと違うように思いますし、IT技術者の意識もSaaSは区別して考える場合が多いようです。

    AWSは最近までSaaSには手を付けていませんでした。マイクロソフトはIaaSとPaaSをAzureとして提供していますが、SaaSは別ブランドです(たとえばOffice 365)。IBMも、IaaSのSoftLayer、PaaSのBluemixを統合しIBM Cloudとしましたが、SaaSは別ブランドです。

    SaaSを特別扱いするのは、それがビジネスと直結しているからです。電子メールやドキュメントツールくらいなら、会社による違いはそれほどありませんが、会計システムだと業界ごとの差は大きく、会社ごとの独自性もあります。

    マイクロソフトもAWSも、業務に直結したアプリケーションの提案は、ビジネスパートナーの仕事です。マイクロソフトはDynamics 365というERPクラウドを持っていますが、これはクラウドプロバイダーとしてはかなり珍しい存在です。

    ただ、近頃のSaaSはアプリケーションから利用するためのAPIが公開されており、実質的なPaaSとして利用できます。CRM(顧客管理)のSaaSで有名なSalesforceは、Salesforce CRMの動作基盤をPaaSとして利用できます。このように、SaaSとPaaSの区別はあまりなくなってきています。

    このように、SaaSは定義的はクラウドですし、実体としてもPaaSに寄ってきたので、名実共にクラウドの一種ではあります。

    それでも、現段階でSaaSをIaaSと同列に並べるのはちょっと抵抗を感じます。

    そういうことを感じながら、「AWS首位陥落」という表現はちょっと違うなあと思いながら書いた記事がこちらです。

    クラウド市場シェアナンバーワンはどこだ?~AWS vs. マイクロソフト~

    2019年7月27日土曜日

    英語版Windows Serverを日本語化する手順

    Azureなどのクラウドが提供する仮想マシンの多くは英語版のOSしか利用できません。AWSの場合は、Community AMIとして日本語化されたものも選べるようですが、Azureにはありません。Azureには、中国語版が最近追加されたので、日本語版も追加される可能性はゼロではありませんが、可能性は低いでしょう。

    そこで、以前「英語版Windows Server 2012 R2を日本語化する手順」というエントリを書きました。しかし、手順を紹介しただけで、画面ショットもありませんでした。

    Windows Server 2019で操作手順が変わったため、改めて画面ショットも付けて書き直しました。

    【図解】英語版Windowsの日本語化~画面ショット付き詳細手順~

    今度は会社の公式ブログに載せてもらいました。

    Windows Server 2019では[コントロールパネル]ではなく、[設定]を使います。Windows Server 2016では[コントロールパネル]と[設定]のどちらでも可能ですが、[設定]の手順がWindows Server 2016と微妙に違います。一方、コントロールパネルを使った手順はWindows Server 2012と同じなので、ブログではWindows Server 2019とWindows Server 2016以前の2つに分けています。

    2019年7月1日月曜日

    マイクロソフトMVPアワード受賞できませんでした

    2003年4月から、連続して受賞してきた「Microsoft MVPアワード」ですが、今回は受賞できませんでした。

    一昨年は書籍が2冊出たのですが、昨年は全くなかったことが要因かもしれません。現在、書籍執筆が2冊進行中なんですが、ちょっと残念です。

    2019年6月26日水曜日

    【Azure】マネージドディスクとイメージ、仮想マシンの課金

    一般にクラウドコンピューティングサービスでは「使った分だけ課金」が基本ですが、何をもって「使ったか」というのはなかなか難しい問題です。


    ストレージアカウントの場合(ページBLOB=非マネージドディスクを含む)

    Azureのストレージは、Standard ページBLOBを使った仮想ディスクだけが「実際に使った分量に対してGB単価で課金」で、その他のストレージは「割り当てた分量に対して課金」です。

    Standard ページBLOB以外のストレージは、いくつかの容量が事前に用意されており、それを選ぶ「カタログ方式」となっています。実際には1GB単位で指定できるのですが、課金はカタログ単位の切り上げになります。たとえば128GBの次は256GBなので、129GBを割り当てると256GBの課金が発生します。

    請求は1ヶ月単位のサイクルで行なわれますが、ストレージの使用が1ヶ月に満たない場合は毎日の平均(日割り計算)となります。

    Azure Storage を月に数日間のみ使用した場合、料金は日割りされますか?

    はい。ストレージ容量は、1 か月にわたり、保存されていたデータ量の 1 日あたりの平均 (GB 単位) を基準に請求されます。たとえば、月の前半は 10 GB のストレージを常に使用し、後半は使用しなかった場合は、ストレージの平均使用量の 5 GB が課金されます。

    (ストレージのFQAより)

    課金は1日のピークで行なわれるので、図の例で6月15日にゼロにするためには、6月14日中に削除しておく必要があります。

    マネージドディスクの場合

    ただし、マネージドディスク(管理ディスク)の場合はStandard HDDを含むすべての種類が割り当て単位で課金されます。また、カタログにある容量を超えた場合は課金が切り上げられます。

    ストレージアカウントと同様、請求は1ヶ月単位のサイクルで行なわれますが、マネージドディスクの使用が1ヶ月に満たない場合は1時間単位の課金となります。

    以下に示す料金が月額になります。管理ディスクを 1 か月未満使用した場合はどのように課金されますか。

    料金は月額を使用して、時間単位で計算されます。たとえば、P15 の Premium SSD は ¥4,896.720 になります (リージョンによって料金が異なります)。10 月は、¥4,896.720/(31 日 x 24 時間) = ¥6.582/時間で課金されます。

    (マネージドディスクのFQAより)


    仮想マシンイメージの課金

    マネージドディスクから仮想マシンイメージを作った場合、「スナップショット」と同等の料金がかかります。「無料」と書いてある記事もあるようですが、課金されることはサポートに問い合わせたので間違いありません。

    しかし、実際に課金状況を調べてみると、はるかに小さな金額しか請求されていません。「課金サポートではこれ以上のことは分かりかねるので、有償の技術サポートに連絡して欲しい」と言われました。詳細が分かったら報告します。


    仮想マシンの課金

    Azureの仮想マシンは、分単位課金です。仮想マシンが実行状態になってから課金がスタートして、最初の1分は無条件に1分が課金されます。

    その後、1分59秒までは追加の課金がなく、2分になってから次の1分の課金が行なわれます。

    AzureのWebサイトには「秒単位課金」という言葉や「時間課金」という言葉が混じっていて混乱していますが、ブログ執筆時点で分単位で課金されることは間違いありません。

    「秒単位課金」は「秒単位計測」の意味のようです。1分59秒までが1分、2分ちょうどから次の1分と、正しく認識するには秒単位の計測が必要です。

    「時間赤金」は課金明細の記載単位だそうです。確かに、利用明細には「0.92 1時間」のように、1時間単位で記載されています。

    ちょっと紛らわしいですね。

    なお、後損仁通り、仮想マシンの課金は単なるシャットダウンでは停止せず、「割り当て解除」状態に移行しないと課金が継続します。ハードウェアの割り当てをしている以上は「使っている」とみなすわけですが、これも直感に反します。理屈が分かれば不思議ではないのですが。

    2019年6月21日金曜日

    【Azure】Azureの仮想マシンにドメインコントローラーを構成する

    Microsoft Azureの仮想マシンにドメインコントローラーを構成する場合、以下の注意が必要です。

    • データベースはCドライブに置かない
    • 仮想ネットワークのDNSサーバーアドレスをドメインコントローラーのものに変更する

    AzureのシステムディスクにはRead/Writeキャッシュが設定されていて、不慮の事態によるデータロスがあり得ます。SLAでは稼働率99.9%とか99.95%となっていても、落ちるときは落ちます。

    ドメインコントローラー昇格時は、ディレクトリデータベースを配置したディスクドライブのキャッシュを無効にするため、データロスの問題は発生しませんが、パフォーマンス劣化の問題があり、いずれにしてもCドライブににディレクトリデータベースを配置するのは好ましくありません。

    と思っていたんですが、Azureキャッシュは無効にできないようです。つまり「データベースはCドライブに置かない」という結論は同じですが、その理由は「予期せぬ停止により、データロスが発生する可能性があるから」ということになります。

    このあたりの話は、以下のコースで扱っています。

    Microsoft Azureによるサイト間ネットワークの構築 ~ハイブリッドクラウド構成の基礎~

    Linuxのお客様も増えてきたので、カリキュラムの変更も考えているのですが、当分の間Windows Serverの話をしています。ただし、最後の1時間くらいです。