Windows Server で動的コンテンツを EC2 + RDS で作ってみるの巻

目的

検証用のアプリケーションを作成する

目標

Web 動的コンテンツから、RDS Mysql へデータ書き込みを行う

環境

EC2 t2.miclo WindowsServer2016
Eclipse 4.7 Oxygen の Windows 64bit Full Edition Java
Tomcat 8

その他、下のサイト参照
https://qiita.com/hatakkkk/items/cb8dd22041d75952c8d7

Eclipse 動かすのに t2.miclo は小さいかも。。。

JDBC の導入

お勉強用に下のサイトを参考にした
http://web.sfc.wide.ad.jp/~tinaba/tutorials/mysql-j/
https://qiita.com/ononoy/items/4961ce6d5b12aff6c108
https://www.qoosky.io/techs/d2beb9dc80

Mysql の JDBCドライバについて、Aamazon から情報が提供されているようなので、下のサイトを確認する。
https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/java-rds.html

Mysql のJDBC ドライバをインストールする

下のサイトから、”mysql-connector-java-5.1.45.zip” をダウンロードする
https://dev.mysql.com/downloads/file/?id=474258

「あれ?ダウンロードが始まらないな?」というときは、
Web サイトの中央下付近にある文章”No thanks, just start my download.” をクリック

今日はここまで。

続きを読む

t2.microインスタンスでWindowsは使い物になるのか?

ICDP(田舎クラウドデザインパターン)的なネタ再び。

概要

AWS EC2 t2.micro インスタンスのシステム資源は非常に乏しい。
AWS無料利用枠でウィンドウズも対象だけど、本当に使い物になるのか?

目的

t2.microインスタンスへWindows Server 2008R2をインストールしてソフトウェアを起動しようとしたところ、 Out of Memory で起動不能であった。
メモリ1GB、連続して演算できない制限付きのCPU能力で、ウィンドウズを使用するには厳しい。
動作させたいソフトウェアは必要メモリ500MBのため、なんとか使えるようにすることを目的とする。

要件

  • AMI
    Windows_Server-2008-R2_SP1-Japanese-64Bit-Base-2017.11.29 – ami-95d06bf3

  • ページファイル(スワップ)無しで使う。
    スワップが発生したら実用にならないためページファイルは無しとする。
    これはスワップ処理にはCPU時間を消費するため、CPU時間に制限があるt2系インスタンスでは動作が間欠的に停止したり、操作不能に陥ったりするからである。

現状

Windows Server 2008R2 をインストールして起動した状態はこのようになっている。
t2a.jpg

消費メモリは959MB。
メモリ1GBしか無いのに消費メモリがこの状況では無理もない。殆ど空きがない。
40MBではメモリ不足で起動不能となるのは当然であろう。

対処

タスクマネージャでメモリ使用状況を見て削減できそうなプロセスを調べる。
t2b.jpg

TrustedInstaller.exe が460MBも使用している。
これは何かと調べると、Windows Modules Installerサービスのようだ。
Windows Update関連のプログラムで、停止させると更新に失敗するが通常は問題無いので停止させてみた。

無効に設定したサービス

先の大物を含め、無効に設定したサービスは以下の通り。
ただしこれを行うとWindows Updateが失敗するので行う場合は手動で起動し対処すること。

  • Windows Modules Installer
  • Windows Update
  • WinHttp Web proxy Auto-Discovery Service

また、AWSオリジナルの制御機能を使わないのであれば以下も無効にできる。
こちらは計20MB程度の削減にしかならないのでお好みで。

  • Amazon SSM Agent
  • AWS Lite Guest Agent
  • Ec2Config

対処した結果

t2c.JPG

消費メモリが400MB程度となり、600MBの空きを確保できた。

結論

かろうじて要件を満たし動作可能な環境を構築できた。
しかし、リソースには余裕が無いためMackerel等で常時監視した方が良いと思われる。

続きを読む

AWSでのWindows Server ディスク拡張

ディスクがやばい。でもAWSなら大丈夫。

SQLのデータベースが肥大化し、ディスクが枯渇していたので拡張を実施。
ダウンタイム無し。さすがAWS。

手順

  1. AWSコンソールよりEBSボリュームの拡張
    「ボリュームが Optimizing 状態になり次第、
    ファイルシステムのサイズ変更を開始できます。」ということ。
    →変更して2、3分でOS上で認識。
  2. OS上でディスク拡張
    画面に従いそのまま完了。

参考
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/ebs-modify-volume.html
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/recognize-expanded-volume-windows.html

拡張サイズについて

本当は2.5TBに拡張しようと思ったけど、
該当のボリュームはMBRなので2.0TBまでしか拡張できない。

  • AWSサポート回答

該当のvol-xxxxxxxxをご利用開始時にGPTでフォーマット済みであれば、2.5TBまで拡張可能です。
MBRの場合には2TBまで拡張し直近での容量不足を回避していただいた後に、新規のGPTフォーマット済みボリュームへのコピーおよびドライブレターの変更による置き換えをご検討ください。

参考
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/volume_constraints.html#window-volumes
http://www1.ark-info-sys.co.jp/support/etc/use/gptsystemdrive.html

続きを読む

CPUの脆弱性におけるEC2の保守対応(Amazon Linux、Windows)

CPUの脆弱性

年明け早々に問題になっている「CPUの脆弱性」について、AWSでの保守についてのメモです。

今回騒ぎになっているのは1月3日にProject Zeroの記事で紹介されたCPU脆弱性。

CPUの脆弱性の影響や対応方法などは、以下の記事がとてもわかりやすかったです。

上記の記事で、問題点や影響について大変わかりやすく解説されているので、この記事で脆弱性の問題は省いて、AWSのEC2における対応を書いて行きたいと思います。

EC2(Amazon Linux、Windows)の対応

Processor Speculative Execution Research Disclosureを簡単に要約すると、

KPTIのバグに対処と、CVE-2017-5754(不正なデータキャッシュ読み込み)の軽減策を改善するカーネルをリリースしました。最新のAmazon LinuxカーネルかAMIにアップデートすることによって対応されたカーネルが使えるようになります。

アップデートを推奨されているサービスは、
EC2EC2 WindowsECS Optimized AMElastic Beanstalk

また、RDSは現段階でユーザーが対応することは無いようです。

今回EC2について対応の流れを紹介していきます。

Amazon Linux

OSがAmazon Linuxの場合、最新のAMI、又はカーネルをアップデートして再起動。
現在(2018年1月11日)アップデートされるカーネルは以下になります。
Linux version 4.9.75-25.55.amzn1.x86_64
https://alas.aws.amazon.com/ALAS-2018-939.html


#対象のインスタンスにログインする
$ ssh hoge-instance

$ sudo su -

# カーネルを確認
# uname -srv
Linux 4.4.5-15.26.amzn1.x86_64 #1 SMP Wed Mar 16 17:15:34 UTC 2016
# 末尾のタイムスタンプはビルドされた日時を指している。

# カーネルをアップデートする
# yum update kernel -y
Loaded plugins: priorities, update-motd, upgrade-helper
amzn-main/latest                                                                                                                                                               | 2.1 kB     00:00
amzn-updates/latest                                                                                                                                                            | 2.5 kB     00:00
mackerel/latest/x86_64                                                                                                                                                         | 2.5 kB     00:00
mysql-connectors-community/x86_64                                                                                                                                              | 2.5 kB     00:00
mysql-tools-community/x86_64                                                                                                                                                   | 2.5 kB     00:00
mysql56-community/x86_64                                                                                                                                                       | 2.5 kB     00:00
8 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package kernel.x86_64 0:4.9.75-25.55.amzn1 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

======================================================================================================================================================================================================
 Package                                    Arch                                       Version                                                 Repository                                        Size
======================================================================================================================================================================================================
Installing:
 kernel                                     x86_64                                     4.9.75-25.55.amzn1                                      amzn-updates                                      18 M

Transaction Summary
======================================================================================================================================================================================================
Install  1 Package

Total download size: 18 M
Installed size: 72 M
Downloading packages:
kernel-4.9.75-25.55.amzn1.x86_64.rpm                                                                                                                                           |  18 MB     00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : kernel-4.9.75-25.55.amzn1.x86_64                                                                                                                                                   1/1

  Verifying  : kernel-4.9.75-25.55.amzn1.x86_64                                                                                                                                                   1/1

Installed:
  kernel.x86_64 0:4.9.75-25.55.amzn1

Complete!

カーネルをアップデート後、awsのコンソール画面より再起動。
(再起動しないとカーネルが更新されない)

# 再起動後
# uname -srv
Linux 4.9.75-25.55.amzn1.x86_64 #1 SMP Fri Jan 5 23:50:27 UTC 2018

脆弱性対応されたカーネル(Linux version 4.9.75-25.55.amzn1.x86_64)になっていることを確認。
このバージョンがビルドされた日も1月5日と最新ですね。

補足:使用しているAMIのバージョンが古い場合は、最新のAMIにアップデートする必要があります。

問題の脆弱性に対応できているか確認する

Linuxが脆弱性「Spectre」「Meltdown」に対応済みか調べる方法の記事を参考に、アップデートされたカーネル(Linux version 4.9.75-25.55.amzn1.x86_64)で検査しまします。

Spectre and Meltdown mitigation detection tool v0.24

Checking for vulnerabilities against live running kernel Linux 4.9.75-25.55.amzn1.x86_64 #1 SMP Fri Jan 5 23:50:27 UTC 2018 x86_64

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  NO  (only 35 opcodes found, should be >= 70)
> STATUS:  VULNERABLE  (heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  YES 
*   Kernel support for IBRS:  NO 
*   IBRS enabled for Kernel space:  NO 
*   IBRS enabled for User space:  NO 
* Mitigation 2
*   Kernel compiled with retpoline option:  NO 
*   Kernel compiled with a retpoline-aware compiler:  NO 
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  YES 
* PTI enabled and active:  YES 
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

A false sense of security is worse than no security at all, see --disclaimer

AWSのProcessor Speculative Execution Research Disclosureに書いてあるように
確かにKPTIのバグ(Variant 3)は対処されていますが、CVE-2017-5754(不正なデータキャッシュ読み込み)の軽減策を改善するだけで、根本的に解決はできていないようです。

Windows 8.1 又は Windows Server 2012 R2

OSがWindows 8.1 又は Windows Server 2012 R2の場合
KB4056898のセキュリティプログラムをインストールします。

手順は対象のwindowsインスタンスからMicrosoft®Update カタログにアクセスし、対象のセキュリティプルグラムをインストール、再起動すれば完了です。

確認は、「コントロールパネル」 > 「システムとセキュリティ」 > 「Windows Update」 >「更新の履歴」
のタブを開き

Windows 用セキュリティ更新プログラム (KB4056898) インストール状態: 成功しました

となっていれば、対応完了です。

補足:更新プログラムしばらく更新していないマシンは、インストールに失敗する場合があるので、「コントロールパネル」 > 「システムとセキュリティ」 > 「Windows Update」 > 「更新プログラムを確認」 を開いて、プログラムを最新のものに更新して再起動してから、上記のセキュリティプログラムをインストールしましょう。

終わりに

今回の対応をとして完全に脆弱性が解決しているわけではないので、継続的にAmazon Linux AMI Security Centerをチェックして、(RSS feed有り)最新のカーネルにアップデートし続けた方が良さそうです。

今回のCPUの脆弱性で多くのマシンを保守していると脆弱性の対応がとても大変だなと痛感しました。エンジニアとして、できるだけ自分達で保守するものが少なくなるように努めて行きたいなと思います。

続きを読む

Setup Radius on AWS for access to WiFi from Anywhere

システム管理 & アマゾンウェブサービス Projects for $250 – $750. We have an AWS instance of Windows Server 2012 R2 – would like to install Active Directory and setup RADIUS so we can have users from our multiple offices authenticate the WiFi credentials… 続きを読む

AWSの3つのインスタンスタイプについて

はじめに

AWS認定ソリューションアーキテクト[アソシエイト]試験を受験するにあたり、
必要な基礎知識を #備忘録 も兼ねて記載していきます。

全体の流れにご興味がある方は、下記記事をご覧ください!
AWS認定ソリューションアーキテクト[アソシエイト] 合格までの奮闘記 (WIP)

01. On-Demand Instance

「On Demand」とは、「要求に応じて、要求があり次第」といった意味を持つ、英単語。

オンデマンドインスタンスとは、自分が使いたいタイミングでインスタンスを起動させて使用するインスタンスタイプです。

オンデマンドインスタンスの1時間当たりの料金は、次の3つの要素で決まります。

  • リージョン
  • インスタンスタイプ
  • OS (Amazon Linux / RHEL / Windows Server など)

最近仕様が変わった点

Linuxインスタンスに関しては、2017年10月2日以降、1秒単位での従量課金モデルに変更。
→ 仮想マシンのOSが起動してからが従量課金の対象となる。
http://itpro.nikkeibp.co.jp/atcl/news/17/091902267/

02. Reserved Instance ( RI )

リザーブドインスタンスは、1年あるいは __3年契約を結ぶことにより、
オンデマンドインスタンスよりも格安に EC2インスタンスや RDSインスタンスを利用できる課金方式です。

リザーブドインスタンスでは、EC2インスタンスの起動 / 停止に関わらず、利用料金が発生します。

オンデマンドインスタンスに対する割引率は、支払方式で変動し、
「前払いなし」、「一部前払い」、「全額前払い」の順で高く、
「1年契約」より「3年契約」の方が高くなります。

03. Spot Instance ( Spot )

スポットインスタンスとは、入札形式の EC2インスタンスの利用 / 支払い方式で、
需要と供給のバランスによって決まるスポット価格 ( 市場価格 ) を入札価格が上回ると、
スポット価格で EC2インスタンスを利用することができます。

スポット価格は、各AZの各インスタンスタイプの需要に基づいて、
その AZ / インスタンスタイプ / OS のスポット価格が決定されます。

【 豆知識 :sunglasses:

2015年10月に「スポットブロック」というオプションがリリースされました。

実行時間が決められているような処理向けにさらに適したEC2を作るために、
有限の時間 ( 1時間から6時間 ) で継続して実行するスポットインスタンスを起動できるようになりました。
処理時間指定向けの新機能 EC2スポットブロック

続きを読む

LightSailでWindows Server立ち上げて日本語化してみた

はじめに

kintoneでSAML認証を使用したSSOを実現するのWindows Server部分の設定です。

ちょっと検証用にサーバー使いたいってなった時に、EC2もラクはラクなんですがもっと手軽なものあるやんけ!ということでLightSail使ってみたのでメモ。

リージョンもいろいろ選べるようになっているのと、うまく使えばEC2よりコスト抑えられるのと、単体でぽこっと立てるだけならこれで十分やんって感じ。

EC2は一応これで1ヶ月あたりのランニング費用を試算。
AWS Simple Monthly Calculator(簡易見積ツール)

LightSailの価格体系

うん。わかりやすい。今回はADとADFS入れるだけで他に何かバックエンドでゴリゴリ動かすわけでもないので、LightSailの1番安いプランにする。
lightsail_plan.png

しかもStaticIP(AWSでいういわゆるEIP)ひとつ付けられるみたいなのでなんだかお得感。
セキュリティグループとか細かく設定したいならEC2のほうがいいかもしれないけど、個人ユースでテスト用って考えるとこれくらいで十分。

構築のプロセス 〜 LightSail起動

マネコンからプランとリージョン選択してぽちぽちするだけでインスタンスが立ち上がる。
東京リージョンも選択できます。
lightsail2.png

インスタンスの名前をつけて・・・
lightsail3.png

WindowsはWS2K16と2K12R2のどちらか選択可能。
特に支障ないのでWS2K16にしたよ。
lightsail4.png

構築のプロセス 〜 立ち上げたLightSailにStaticIPアタッチ

起動までは数分もかからない。この時点でもPublicIPは振られるんだけど、これがおそらくrebootとかかけるとIPが変わっちゃう。なのでIPを固定化するためにStaticIPをアタッチする。
lightsail5.png

アタッチする時も画面に沿って設定するだけ。
lightsail6.png

StaticIPがアタッチされた。
lightsail7.png

アタッチした後はIP表示のところにピンマークが付きます。
lightsail8.png

Windows Server 〜 ログイン

ここまでできたらいよいよログインです。ラクなのがなんとRDP用のターミナルがあるんだよ。セルフで自分のRDP Clientを利用することも可能だけど、特に問題なかったらこれで十分かも。
lightsail10.png

Windows Server 〜 ロケール設定

デフォルトのロケールが英語なので、そのままでも良いんだが今回はわかりやすいように日本語に変更する。
ロケールの設定は普通のWindowsと同じ。
Add a languageで言語を追加してOptionsからLanguage Packをダウンロードする。
lightsail11-1.png

その後Set as defaultでデフォルト設定にする。
lightsail14-1.png

サインインし直すと言語変わるよーと出ているのでログインし直す。
lightsail12.png

ちゃんと日本語になってることを確認。
lightsail13.png

このあとWindows Updateとかかけたけど時間帯のせいなのかレスポンスが重かった。。。
午前中とかだとRDPのターミナルとかもさくさく快適だし、試す時間帯は考えたほうがよさげ。

続きを読む

VMware NSX Cloud の Overlayネットワーク

NSX Cloud

NSX Cloudはパブリッククラウド(現時点で対応しているのはAWSのUSリージョンのみ)に対して、ネットワークとセキュリティ機能を提供するサービスです。パブリッククラウド内の論理ネットワークを単一の管理画面で管理し、複数のパブリッククラウドに関するネットワーク及びセキュリティに対して共通のAPIを提供します。
NSX Cloudが提供する分散ファイアウォールを利用することにより、パブリッククラウド上のワークロードを保護、隔離することができます。分散ファイアウォールによって実現されるマイクロセグメンテーションセキュリティルールは、インスタンス名、OSタイプ、AMI-ID、ユーザ定義タグを利用してダイナミックに設定することができます。
従来のVMware製品と大きく異なるのは、VMwareのハイパーバイザーを必要としない点と、サービスとして提供される点です。

メリット

  • 複数のAWSアカウントを持ち、それぞれのアカウントに複数のVPCが存在する場合、これらを一元的に管理することは困難です。NSX Cloudを利用することにより、単一の管理画面から複数アカウントのVPCを表示し、各VPC内のインスタンスの状態を把握することが可能になります。
  • 通常AWS利用者はインスタンス作成時に、適切なセキュリティグループを適用する必要がありますが、NSX Cloudを利用することにより、NSX Cloudの管理者が設計したポリシーを利用者に強制し、利用者はインスタンスの名前やタグによって適切なセキュリティポリシーを選択することが可能になります。
  • (将来的に)複数のパブリッククラウドにおけるネットワーク・セキュリティの管理をNSX Cloudが提供する単一のAPI/管理画面から一元的に行い、クラウド毎に異なる管理画面を操作する必要がなくなります。

csm.gif

コンポーネント

NSX Cloudは以下のコンポーネントで構成されます。

  • CSM (Cloud Service Manager)

    • AWS環境のインベントリ情報の取得と、AWSのAPIを利用してNSX Managerの設定内容とAWS環境内の構成を同期する。
    • VMwareの所有するVPC内で起動し、NSX Cloudサービスの一部として提供される。
  • NSX Manager
    • 論理ネットワークとセキュリティ機能を管理するためのAPIとGUIを提供。
    • VMwareの所有するVPC内で起動し、NSX Cloudサービスの一部として提供される。
  • NSX Controller
    • 論理ネットワークとセキュリティ機能に関する状態の管理と制御。
    • VMwareの所有するVPC内で起動し、NSX Cloudサービスの一部として提供される。
    • CCP – Central Control Planeとも呼ばれる
  • PCG (Public Cloud Gateway)
    • CSMの管理画面を利用して、NSX Cloudの管理対象となるVPC上にデプロイする。
    • NSX Controllerと通信を行い、論理ネットワーク及びセキュリティ機能に関する状態の管理と制御をVPC単位で提供する。
    • LCP – Local Control Planeとも呼ばれる。
    • Overlay構成を利用する場合、North-Southトラフィックのゲートウェイとして利用され、ルーティングとNATを提供する。
  • NSX Cloud Agent
    • AWS上で起動するインタンス(VM)に対してインストールするNSX Cloud向けのモジュール。現時点でUbuntu 14.04とWindows Server 2012に対応。PCGからダウンロードしてインストールする。

利用形態

2種類の利用形態があります。

Kobito.geIJCp.png

  • Micro Segmentation モード

    • PCGはデータパスではなくローカルコントロールプレーンとして機能
    • NSXの分散ファイアウォール機能によるアプリケーションの分離
    • インスタンスの属性に基づく動的なファイアウォールポリシーの設定
    • ルーティング等のネットワークサービスはAWSのVPC機能を利用
  • Overlay モード

    • NSXの分散ファイアウォール機能によるアプリケーションの分離
    • GENEVEカプセル化による論理スイッチへの接続
    • 分散ルーティング
    • Edge Gateway Serviceが以下のサービスを提供
      • OverlayとUnderlayの接続
      • Overlayネットワーク向けのDNAT/SNAT
      • Overlayネットワーク向けのDHCP

使い方の概要

  1. NSX Cloudを契約する (CSMとNSX Manager/Controllerがデプロイされ、管理画面にログイン可能になります)
  2. AWS管理画面からCloudFormatinoテンプレートを実行してIAMの設定を行う(CSMからAWSを管理するために利用するIAM Roleが作成されます)
  3. AWS管理画面からCloudFormatinoテンプレートを実行してVPCを作成する
  4. CSMから管理対象のVPCに対してPCGを作成する
    • PCGは3つのサブネットに対してインターフェースを持ちます
    • NSX Cloudで利用されるSecurity GroupがVPCに対して作成されます
  5. インスタンスにNSX Cloud Agentをインストールする
  6. NSX ManagerにDHCPサーバーを作成し、Logical Switchに接続する (* Overlayモードの場合のみ)
  7. 自動的に作成されているTier-0 Routerに対してLogical Switchを接続する (* Overlayモードの場合のみ)
  8. インスタンスにnsx:networkタグを適用する
    • Microsegmentation Modeの場合 : nsx:network = default
    • Overlay Modeの場合 : nsx:network = 接続するLogical SwitchのID

設定に利用するCloudFormationテンプレートははNSX Cloudの管理画面からダウンロード可能です。

VPCの構成

CloudFormationテンプレートによって作成されるVPCにはUplink/Downlink/Managentの3種類のサブネットが存在します。デフォルトの状態ではDownlikサブネットはPrivate Route Tableに構成され、インターネットゲートウェイには接続されていないので注意が必要です。

Kobito.ga1TQA.png

PCGの作成

CSMからVPC上にPCGを作成します。作成時には、PCGを作成するAvailable Zoneを選択し、PCGを接続するUplink/Downlink/Managemntのサブネットを選択します。PCGをHigh Availability構成にする場合、Avalability Zoneを複数指定します。

Kobito.Mecpzm.png

こんな形でPCGが作成されます。

Kobito.GCxjPB.png

Overlayモードに関して

Overlayモードでは、Downlinkサブネットに接続されたインスタンス上に、Overlayネットワークが構成され、VPC外とのNorth−SouthトラフィックはPCGによりルーティング/NATされます。
NSX Manager上で、Overlayネットワーク向けにDHCPサービスを提供することで、Overlayモードに参加する各インスタンスはNSX IPが割り当てられ、NSX Cloud Agentのインストールによって設定されるopenvswitchのブリッジとネットワークネームスペース上に設定されます。

NSX Cloud Agentのインストール

Ubuntu 14.04もしくはWindows Server 2012のAMIからインスタンスを作成し、Downlinkサブネットに接続します。踏み台用のインスタンスを用意して、踏み台経由で作成したインスタンスにアクセスし、以下のようにAgentインストール用のスクリプトをダウンロードします。(PCG作成時にRoute53にAレコードとして、nsx-gw.vmware.localがPCGの管理用アドレスとして追加されています。)

ubuntu@ip-10-99-3-248:~$ wget http://nsx-gw.vmware.local:8080/factory_default/trusty_amd64/install_nsx_vm_agent.sh
ubuntu@ip-10-99-3-248:~$ chmod +x install_nsx_vm_agent.sh
ubuntu@ip-10-99-3-248:~$ sudo ./install_nsx_vm_agent.sh

インストールスクリプトによりopenvswitch 2.7等NSX Cloudに必要なパッケージがインストールされます。上記コマンドによりapt-get updateが実行されるため、インストール時はPublic IPが必要になります。

nsx:networkタグの追加

NSX Cloud Agentインストール後、インスタンスをNSXの管理対象とするには、インスタンスに対してnsx:networkタグを付与します。タグの値はOverlay VMを接続する先のLogical Switchに関するNSX Switch Tagの値を指定します。この値はCSM上で確認することができます。(Micro-segmentationモードで利用する場合は、値としてdefaultを指定します)

NSX Switch Tagの確認

Kobito.v5RZw1.png

インスタンスに対するタグの追加

Kobito.PdWsoW.png

タグの追加により、インスタンスはNSXの管理対象となり、NSX Manager上で指定したLogical Switchに対して接続されます。Overlay VMの場合はDownlinkサブネット(Underlayネットワーク)で利用されるsshdがポート8888番で起動し、Underlayネットワーク経由ではインスタンスに対してポート22番でsshアクセスができなくなります。

nsxcliによる状態の確認

NSX Cloudの管理下になったインスタンスでは、nsxcliコマンドで状態を確認することができます。

ubuntu@ip-10-99-3-248:~$ sudo nsxcli

ip-10-99-3-248> get gateway connection status
Public Cloud Gateway  : nsx-gw.vmware.local:5555
Connection Status     : **ESTABLISHED**
Connection Time       : Fri Dec 22 05:22:18 2017

ip-10-99-3-248> get vm-network-mode
VM-Network-Mode : **overlay**
Interface       : eth0

インスタンスのネットワーク構成

Overlay VMではインスタンス内でopenvswitch有効になり、Underlay用のveth(nsx-vtep0.0)と、Overlay用のveth(nsx-eth0)がIPアドレスを持ちます。Downlinkサブネット内のインスタンスは、nsx-vtep0.0間でオーバーレイネットワークを利用して通信できるようになります。

ovsの設定

ubuntu@ip-10-99-3-248:~$ sudo ovs-vsctl show
413bddd4-4ec0-4cfc-9958-eb2efa481862
    Manager "unix:/var/run/vmware/nsx-agent/nsxagent_ovsdb.sock"
        is_connected: true
    Bridge nsx-switch
        Controller "unix:/var/run/vmware/nsx-agent/nsxagent_vswitchd.sock"
            is_connected: true
        fail_mode: secure
        Port "eth0"
            Interface "eth0"
        Port "nsx-vtep0.0"
            Interface "nsx-vtep0.0"
                type: internal
        Port nsx-switch-
            Interface nsx-switch-
                type: patch
                options: {peer="nsx-switch+"}
        Port nsx-switch
            Interface nsx-switch
                type: internal
    Bridge nsx-managed
        Controller "unix:/var/run/vmware/nsx-agent/nsxagent_vswitchd.sock"
            is_connected: true
        fail_mode: secure
        Port "nsx-switch+"
            Interface "nsx-switch+"
                type: patch
                options: {peer=nsx-switch-}
        Port nsx-managed
            Interface nsx-managed
                type: internal
        Port "geneve174261036"
            Interface "geneve174261036"
                type: geneve
                options: {csum="true", key=flow, remote_ip="10.99.3.44", tos=inherit}
        Port "geneve174261243"
            Interface "geneve174261243"
                type: geneve
                options: {csum="true", key=flow, remote_ip="10.99.3.251", tos=inherit}
        Port "geneve174261061"
            Interface "geneve174261061"
                type: geneve
                options: {csum="true", key=flow, remote_ip="10.99.3.69", tos=inherit}
        Port "nsx-eth0-peer"
            Interface "nsx-eth0-peer"
    ovs_version: "2.7.0.6814985"

vethのIPアドレス

デフォルトのネットワークネームスペースに、Underlay用のvethとIPアドレスが構成されます。

ubuntu@ip-10-99-3-248:~$ ip a show dev nsx-vtep0.0
6: nsx-vtep0.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 06:17:1e:54:96:3a brd ff:ff:ff:ff:ff:ff
    inet 10.99.3.248/24 brd 10.99.3.255 scope global nsx-vtep0.0
       valid_lft forever preferred_lft forever
    inet6 fe80::417:1eff:fe54:963a/64 scope link
       valid_lft forever preferred_lft forever

nsx-rootネットワークネームスペースに、Overlay用のvethとDHCPで払い出されたIPアドレスが構成されます。

ubuntu@ip-10-99-3-248:~$ sudo ip netns exec nsx-root ip a show dev nsx-eth0
9: nsx-eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8943 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 06:17:1e:54:96:3a brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.3/24 brd 192.168.100.255 scope global nsx-eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::417:1eff:fe54:963a/64 scope link
       valid_lft forever preferred_lft forever

Overlayネットワークにおける通信

OverlayネットワークのパケットはGeneve(draft-ietf-nvo3-geneve-05)によってカプセル化されて通信が行われます。Underlayネットワークとしては、VPCのサブネット(Downlink)が利用されます。

geneveパケット

インスタンスのnsx-rootネームスペースでパケットをキャプチャすると、送受信されるパケットがgeneveによりカプセル化されていることが確認できます。tcpdumpはgeneveパケットをデコードできるため、アウター/インナーヘッダの内容を確認することができます。
Overlayネットワークでは、分散ルーティングが利用できるため、異なるLogical Switchに接続されたインスタンス同士のL3通信が、Underlayネットワークでルーティングされずに通信できています。

06:26:11.607582 IP (tos 0x0, ttl 64, id 17009, offset 0, flags [DF], proto UDP (17), length 142)
    10.99.3.251.49289 > 10.99.3.248.6081: Geneve, Flags [C], vni 0x238c, options [class VMware (0x104) type 0x80(C) len 8]
    IP (tos 0x0, ttl 63, id 56060, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.99.9 > 192.168.100.3: ICMP echo request, id 7079, seq 938, length 64
06:26:11.607660 IP (tos 0x0, ttl 64, id 22643, offset 0, flags [DF], proto UDP (17), length 142)
    10.99.3.248.666 > 10.99.3.251.6081: Geneve, Flags [C], vni 0x2388, options [class VMware (0x104) type 0x80(C) len 8]
    IP (tos 0x0, ttl 63, id 48220, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.100.3 > 192.168.99.9: ICMP echo reply, id 7079, seq 938, length 64

VPC外部からOverlay VMに対する通信

外部に公開したいインスタンスに対してnsx:publicipタグとしてAWSのElastic IPを割り当てることにより、指定したelastic ipを利用してOverlay VMを公開することが可能です。

Kobito.eFuMg8.png

2段階のNAT

上記の設定を行うことにより、CSMがEC2/VPCの設定を変更し、nsx:publicipとして指定されたElastic IPはPCGのUplink InterfaceのセカンダリIPに対して有効になります。Elastic IP向けに着信したパケットはPCGのUpliknインターフェースのセカンダリIPアドレスに変換され、PCGに着信します。PCGはセカンダリIP向けに着信したパケットをもう一度NSX IPに変換し、PCG配下にあるインスタンスに対してパケットを転送します。

Kobito.IjbV5V.png

NSX Manager上のNAT設定

インスタンスに対して、nsx:publicipタグを追加すると、CSMがこれを検出してNSX Managerに対して必要なNATルールを追加します。

Kobito.8ox2g1.png

まとめ

NSX Cloudを使って、AWS VPC内でオーバーレイネットワークを作成し、インターネットと通信できることを確認できました。
NSX Cloudは主にオンプレ向けに販売されているNSX-Tとほぼ同じバイナリを利用しており、NSX-Tに加えて、CSMを利用することで、パブリッククラウドとの連携を実現しているようです。NSX Managerの管理画面はNSX-Tとほぼおなじ機能を提供し、VPCにデプロイされるPCGはNSX-TのTier-0と同等のものです。将来的にはオンプレも含めて管理できるようになるんじゃないでしょうか。

続きを読む

#AWS認定ソリューションアーキテクト[アソシエイト]のテスト勉強をしていて気になった点についてまとめてみた記事。(WIP)

はじめに (2017/12/20)

せっかく業務でAWSを触る機会があるのだから、触り倒してAWS認定資格でも
取ってやろうと画策したのが本記事の執筆の始まり。読者のためでもなく、
自分がテスト勉強をした際の備忘録として、Qiitaを活用してみたいと思う。

他の方が合格体験記等を執筆されていたりするが、これがおもしろいし、役に立つので、
他の記事に負けないよう執筆していきたいと思います。

これといって勉強方法が確立されている訳ではないので、問題を解いたり、実際に触ったりして、
来年2018年2月中の合格を目指したいと思う。

Design for Failure

AWSには、Design for Failure ( 障害に耐えうる設計 ) という設計思想があります。

Design For Failure – 基本原則

  • 単一障害点(Single points of failure)の排除
  • 全てが故障すると仮定して、保守的に設計する
  • Goal: 物理ハードウェアが故障して、消失したり交換されてもアプリケーションは機能する
  • 障害からの復旧を計画する
  • ビジネスニーズと高可用性実現コストのトレードオフ

AWSを用いた耐障害性の高いアプリケーションの設計 ( 18 / 31 )

on-premiss [ オンプレミス = 自社運用(型) ]

そもそもクラウドの対義語として使われているオンプレスという言葉の意味を
みなさんは理解しているだろうか?かくいう私もその一人で会社に入社したころから、
AWSやAzureといったクラウドでシステム構築を行うことが普通だったので、
オンプレミスでシステム開発を行うといった現場にいまだかつて遭遇したことがない。

image.png

オンプレミス(on-premiss)とは、情報システムのハードウェアを使用者(通常は企業)が自社保有物件や
データセンター等の設備内に設置・導入し、それらのリソースを主体的に管理する運用形態をいう。
※【 premiss 】とは、建物という意味を持つ単語の複数形。

【 Instance Type 】

01. On-Demand Instance

「On Demand」とは、「要求に応じて、要求があり次第」といった意味を持つ、英単語。

オンデマンドインスタンスとは、自分が使いたいタイミングでインスタンスを起動させて使用するインスタンスタイプです。

オンデマンドインスタンスの1時間当たりの料金は、次の3つの要素で決まります。

  • リージョン
  • インスタンスタイプ
  • OS (Amazon Linux / RHEL / Windows Server など)

最近仕様が変わった点

Linuxインスタンスに関しては、2017年10月2日以降、1秒単位での従量課金モデルに変更。
→ 仮想マシンのOSが起動してからが従量課金の対象となる。
http://itpro.nikkeibp.co.jp/atcl/news/17/091902267/

02. Reserved Instance ( RI )

リザーブドインスタンスは、1年あるいは 3年契約を結ぶことにより、
オンデマンドインスタンスよりも格安に EC2インスタンスや RDSインスタンスを利用できる課金方式です。

リザーブドインスタンスでは、EC2インスタンスの起動 / 停止に関わらず、利用料金が発生します。

オンデマンドインスタンスに対する割引率は、支払方式で変動し、
「前払いなし」、「一部前払い」、「全額前払い」の順で高く、
「1年契約」より「3年契約」の方が高くなります。

03. Spot Instance ( Spot )

スポットインスタンスとは、入札形式の EC2インスタンスの利用 / 支払い方式で、
需要と供給のバランスによって決まるスポット価格 ( 市場価格 ) を入札価格が上回ると、
スポット価格で EC2インスタンスを利用することができます。

スポット価格は、各AZの各インスタンスタイプの需要に基づいて、
その AZ / インスタンスタイプ / OS のスポット価格が決定されます。

【 豆知識 :sunglasses:

2015年10月に「スポットブロック」というオプションがリリースされました。

実行時間が決められているような処理向けにさらに適したEC2を作るために、
有限の時間 ( 1時間から6時間 ) で継続して実行するスポットインスタンスを起動できるようになりました。
処理時間指定向けの新機能 EC2スポットブロック

勉強時参考にさせていただいたサイト

大変お世話になりました。ありがとうございました。

続きを読む

クラウドベンダーの比較

はじめに

3大クラウドと呼ばれているAWS、GCP,Azureのリソースを比べてみました。
2017年11月時点の比較となります。

インフラ・サービスレベル

比較項目 AWS GCP Azure 備考
データセンター 各地で借りている すべて自前 各地で借りている(一部自前)
仮想化技術 Xen KVM Hyper-V
リージョン(国内) 1個所 1個所 2個所
リージョン(全国) 15個所 12個所 36個所
SLA 99.95 99.95 99.95 仮想サーバ

サービス面

比較項目 AWS GCP Azure 備考
仮想サーバ Amazon EC2 Google Compute Engine Azure Virtual Machines
仮想サーバ対応OS Amazon Linux,CentOS,RedHat,Windows Server,等 CentOS,RedHat,SLES,Windows Server,等 CentOS,RedHat,Windows Server,等
仮想サーバディスク SSD,HDD SSD,HDD SSD,HDD
仮想サーバスナップショット
仮想サーバオートスケール
コンテナ Amazon ECS Container Engine Container Service
RDB RDS Cloud SQL SQL Database
RDB冗長化
RDBリードレプリカ
RDB DB種別 Aurora,MySQL,MariaDB,Oracle,SQL Server,PostgreSQL MySQL,PostgreSQL SQL Server
NoSQL DynamoDB Cloud Datastore Cosmos DB
ビックデータ Redshift BigQuery App Service
メール Amazon SES
モニタリングツール CloudWatch Stackdriver Azure Monitor
ロードバランサー(L4) CLB Network load balancing Azure Load Barancer
ロードバランサー(L7) ALB HTTP load balancing Application Gateway
CDN Amazon CloudFront Google Cloud CDN Azure CDN
VPN Amazon VPC Google Cloud VPN VPN Gateway
DNS Route53 Google Cloud DNS Azure DNS
専用線 Direct connect Dedicated Interconnect Express Route

サポート面

比較項目 AWS GCP Azure 備考
ランク低 開発者 ($29/月 or 利用料の 3%/月) シルバー ($150/月) Standard($300/月)
ランク中 ビジネス($100/月 or 利用料 の10%/月) ゴールド($400/月) Professional Direct($1,000/月)
ランク高 エンタープライズ($15,000/月 or 利用料の10%) プラチナ(問合せ) Premier(問合せ)

費用面(リージョン日本)

比較項目 AWS GCP Azure 備考
課金単位
ディスカウント リザーブドインスタンス(前払い) 継続利用割引、利用確約の割引(前払い) エンタープライズ契約(前払い)
仮想サーバ(Type) t2.medium(2vCPU,4GB) n1-standard-2(2コア,7.5GB) A2 V2(2コア,4GB)
仮想サーバ(時) $0.0464(5.336円)※1 $0.0950(10.925円)※1 $0.15(17.25円)※1
仮想サーバ(月) $33.408(3841.92円)※1 $48.17(5539.55円)※1,※2 $108(12,420円)※1
インターネットへの転送量 $0.140/GB(10TBまで) $0.12/GB(1TBまで) $0.138/GB(5GB-10TB、5GBまでは無料)
ストレージ利用料 $0.025/GB (最初の50TB/月まで) ※S3 $0.016/GB 月 ※Regional Storage $0.2/GB(最初の50TB/月まで) ※BLOG Storage

※1 $1=115円換算
※2 継続利用割引含む

総括

 AWS、GCP,Azureでのサービス面では同じようなサービスを展開していることが判明。
 インフラ・サービスレベルでは、Azureがリージョン36個とTOPに。
世界的に見て幅を利かせているように思えた。
ただ、GCPはすべて自前のセンターでクラウドサービスを展開していることから、
新しいことをやるにも制約が低いように思えた。
私のイメージ的に一番シェアが高いAWSは、インフラ面ではGCP,Azureに劣っている結果となった。
 費用面では、Azureは割高。AWSが思ったよりも頑張っているように思えた。
 イメージ的にGCPは費用は安いと思っていたが、仮想サーバ比較だと、継続利用割引を使用してもAWSのほうが安い結果となった。
 ただ、費用に関しては、日々値下げ合戦が繰り広げられているので、今後のベンダーさんの努力に期待です。

最後に、費用面での算出に使用した見積もりツールです。
【AWS】http://calculator.s3.amazonaws.com/index.html
【GCP】https://cloud.google.com/products/calculator/?hl=ja
【Azure】https://azure.microsoft.com/ja-jp/pricing/calculator

続きを読む