めもめも

このブログに記載の内容は個人の見解であり、必ずしも所属組織の立場、戦略、意見を代表するものではありません。

OpenStackユーザーのためのGoogle Cloud Platform入門(パート4)

前置き

これは、GCPの公式文書ではありません。公式ドキュメントについては、公式ホームページを参照ください。

Google Cloud Platform

実際に試してみたい方は、60日の無料トライアルをお試しください。(クレジットカードの登録が必要ですが、トライアル終了後は明示的に課金設定を行わない限り、勝手に課金されることはありませんので、ご安心ください。)

cloud.google.com

本記事のパート3はこちらです。

enakai00.hatenablog.com

パート4では、Web3層アプリケーションを例として、どのようなコンポーネントを組み合わせてシステムを作るのかを比較してみます。

OpenStackによる構成例

OpenStackクラウドインテグレーション」では、次のような構成例が紹介されています。

ロードバランサー、Webサーバー、Webアプリケーションサーバー、DBサーバーからなる、典型的なWeb3層アプリケーションを構築するもので、複数のデータセンターを利用して、DR構成を実現しています。上記の書籍にしたがって、この環境を構築した場合、次のようなコンポーネントが利用されることになります。

・ネットワーク(Neutron)
・VMインスタンス(Nova)
・セキュリティグループ(Nova)
・Cinderボリューム(Cinder)
・オブジェクトストレージ(Swfit)

これらのコンポーネントの構成を順番に説明していきます。

なお、上記の書籍では、1つのリージョンの複数のAvailability Zone(以下、ゾーン)を用いてDRを実現する想定になっていますが、パート1で説明したように、現在のOpenStackでは、地理的に離れた場所で複数ゾーンを構成するのはそれほど簡単ではありません。ここでは、複数のリージョンを用いて、DRを実現する想定とします。(OpenStackの場合、同一リージョンのゾーンは、コントローラーノードを共有している点に注意してください。)日本国内の2箇所のデータセンターに、別リージョンとして、独立したクラスターを構成しているものとしてください。

ネットワーク

前述の書籍では物理ネットワークをクラウド上で再現するために、複数のサブネットを作成していますが、ここでは、単一のサブネットを用いて、セキュリティグループでインスタンス間の通信を制限することにします。この場合、それぞれのリージョンに単一のサブネットを用意するだけなので、仮想ネットワークの構成はシンプルになります。

VMインスタンス

上記の書籍では、ロードバランサー、Webサーバー、Webアプリケーションサーバー、DBサーバーをすべてVMインスタンスとして導入しています。ロードバランサーについては、LBaaS(Load Balancer as a Service)の機能を利用することも可能ですが、オープンソースとして標準提供されるプラグインはサンプル実装の位置づけとなっており、本格的に利用するにはサードパーティーの商用プラグインが必要となります。

セキュリティグループ

OpenStackのセキュリティグループでは、サーバーの役割ごとにセキュリティグループを定義して、受信を許可するパケットを指定します。パケットの送信元をセキュリティグループで指定することもできるので、全体として、次のようなセキュリティグループを定義することになります。

Security Group Source Protocol
load-balancer any HTTP/HTTPS
Management Subnet SSH
web-server load-balancer HTTPS
Management Subnet SSH
web-application web-server TCP8080
Management Subnet SSH
database web-application MYSQL
Management Subnet SSH

「Management Subnet」は、システム管理者が外部からインスタンスにSSHログインする際の接続元ネットワークのサブネットレンジを与えます。また、クライアントとのSSL通信はロードバランサーでターミネートして、Webサーバーとの通信にはHTTPS、Webアプリケーションサーバーとの通信にはTCP8080を使用します。データベースには、MySQLを使用するものとしています。

この上で、それぞれのインスタンスに対して、次のようにセキュリティグループを割り当てます。

Instance Security Group
Load Balancer load-balancer
Web Server web-server
Web Application Server web-application
Database Server database
Cinderボリューム

VMインスタンスの接続するディスクには、Ephemeral DiskとCinderボリュームがありますが、永続保存が必要なデータには、Cinderボリュームを使用する必要があります。今回の構成では、DBサーバーのデータ保存領域には、Cinderボリュームの使用が必須となります。

オブジェクトストレージ

DBサーバーのデータバックアップをオブジェクトストレージに取得します。

DRの切り替え手順について

DRでリージョンを切り替える際は、オブジェクトストレージに取得したデータベースのバックアップを切り替え先のDBサーバーにリストアします。この前提として、オブジェクトストレージ自体が複数のリージョンにレプリケーションされる構成で、データセンター障害に対する冗長性を持っている必要があります。

この他には、ゾーン間でデータベースのレプリケーションを行うという方法もありますが、地理的に離れた場所の場合、ネットワーク帯域の不足に伴う問題が発生する可能性もあるので注意が必要です。

また、外部からアクセスするIPアドレスについては、リージョン間で同一のグローバルIPを使用することができないため、IPアドレスの変更を外部のクライアントに意識させないためには、DDNSを利用して、DNSに登録するIPアドレスを変更するなどの作業が必要となります。

GCPによる構成例

GCPでは、データベースとロードバランサーについては、マネージドサービスとして機能が提供されていますので、VMインスタンスとして機能を用意する必要はありません。また、GCPが提供するネットワークは、同一のリージョンであれば、ゾーン間においても、ゾーン内と同等のネットワーク帯域が提供されています。そのため、単一リージョンにおける複数のゾーンを利用することで、比較的簡単に独立したFailure zone(故障域)にまたがる冗長性を実現することができます。これらの点に注意すると、次のようなコンポーネントを利用して、前述のOpenStackの場合と同等の環境を構築することが可能です。

全体像を先に示すと、次のようになります。


ネットワーク

GCPのネットワークでは、複数ゾーンにまたがったサブネットが構成できるので、使用するリージョンに単一のサブネットを作成します。

VMインスタンス

WebサーバーとWebアプリケーションサーバーをVMインスタンスとして構築します。

ファイアウォールルール

GCPのファイアウォールルールでは、インスタンスに付与したタグを用いて送信先を指定します。送信元については、サブネットレンジ、もしくは、タグでの指定が可能ですので、次のようなルールを用意することになります。

Source Destination Protocol
130.211.0.0/22 web-server HTTP, HTTPS
web-server web-application TCP8080
Management Subnet web-server, web-application SSH

「130.211.0.0/22」はロードバランサーがWebサーバーにアクセスする際の送信元のサブネットレンジです。また、「Management Subnet」は、システム管理者が外部からインスタンスにSSHログインする際の接続元ネットワークのサブネットレンジを与えます。「web-server」と「web-application」は、WebサーバーとWebアプリケーションサーバーのインスタンスに付与するタグになります。セキュリティグループのように、インスタンスにルールを割り当てるのではなく、インスタンスには、単純にタグを付与するだけでよい点に注意してください。

Webアプリケーションサーバーからデータベースへの接続については、後述のCloud SQLの設定を用いて、接続を許可するIPアドレスを指定します。

HTTP(S)ロードバランサー

GCPが提供するロードバランサーは、単一のグローバルIPアドレス(VIP)で複数のリージョン、ゾーンに負荷分散することが可能です。この後で説明するように、複数のゾーンから同一のデータベースを参照することもできるので、両方のゾーンを同時に使用する構成で、複数データセンターを用いた冗長構成が実現できます。

Cloud SQL

Cloud SQLは、MySQLのマネージドサービスで、レプリケーションによる複数ゾーンにまたがった冗長構成を取ることが可能です。定期的なバックアップ処理、あるいは、障害時のフェイルオーバー処理も自動化されています。また、前述のように、GCPのネットワークでは、ゾーン間においてもゾーン内と同等のネットワーク帯域が確保されているので、それぞれのゾーンのWebアプリケーションサーバーから同一のデータベースにアクセスすることも問題ありません。

DRの切り替え手順について

上記で説明したように、両方のゾーンを同時に使用する構成をとることにより、データセンター障害時に特別な切り替え手順が発生することはありません。ロードバランサーが単一のグローバルIPアドレス(VIP)を提供するため、クライアントからのアクセス先が変わることもありません。

この例からも分かるように、Compute Engineとマネージドサービスを適切に組み合わせることで、シンプルで可用性の高い環境を構築することが可能になります。

Introduction to Google Cloud Platform for OpenStackers (Part III)

Disclaimer

This is not an official document of Google Cloud Platform. Please refer to the GCP web site for the official information.

cloud.google.com

Part II of this article series is here.

enakai00.hatenablog.com

In this part, I will give a comparison between OpenStack Nova/Cinder and Compute Engine regarding VM instance management.

Instance size

In OpenStack, you would choose the "Instance Type" to specify the instance size (number of vCPUs and amount of memory). Instance Types are predefined by the sysadmin. General users are not allowed to add custom types.

On the other hand, in Compute Engine, instance sizes are defined as "Machine Type". In addition to choosing one from predefined Machine Types when you create a new instance, you can change the number of vCPUs and amount memory separately, to create your own "Custom Machine Type."

Reference:

Storage options

OpenStack: Ephemeral Disk and Cinder Volume

OpenStack provides two different kinds of instance attached disks, "Ephemeral Disk" and "Cinder Volume". Initially, Ephemeral Disk was intended to be used as a system disk containing operating system files whereas Cinder Volume was to store persistent application data. However, Live Migration is not available with Ephemeral Disk, people often use Cinder Volume for a system disk, too.

When you choose Ephemeral Disk for a system disk, the OS template image (managed by Glance) is cloned into the local storage of compute node, and the local image is directly attached to the instance. When you destroy the instance, the attached image is also destroyed. On the other hand, Cinder Volume provides a persistent disk area (LUN) which resides in the external storage box. In typical configuration, the disk area (LUN) is attached to the compute node using the iSCSI protocol, and attached to the instance as a virtual disk. Even when you destroy the instance, the attached volume remains in the external storage. You can reuse the volume by attaching to a new instance.

  • Comparing Ephemeral Disk and Cinder Volume

Since the disk image is stored in the local storage of the compute node, Ephemeral Disk is sometimes used to achieve better storage performance. It is also possible to use multiple storage boxes with different performance characteristics for the backend device of Cinder Volume. Users can specify the preferred backend in creating a new Cinder Volume.

In addition, applications running on the instance can access the object storage provided by OpenStack Swift.

Compute Engine: Persistent Disk and Local SSD

Compute Engine provides "Persistent Disk" as a persistent storage attached to an instance which corresponds to "Cinder Volume" of OpenStack. It is used for a system disk containing operating system files, and for storing persistent application data as well. The data is automatically encrypted when it goes out of the instance to the physical storage. A single Persistent Disk can be extended up to 64TB, but the maximum total capacity of the attached disks is restricted based on the instance size.

When you need a high performance local storage, you can also use the local SSDs. By attaching eight SSDs with each of 357GB capacity, you can use 3TB of local SSDs in total. Even with local SSDs, Live Migration is available. Since the data in local SSDs are copied between instances during Live Migration, there may be a temporally decrease in storage performance though.

In addition, applications running on the instance can access the object storage provided by Cloud Storage.

Reference:

Instance Metadata

OpenStack: Metadata Service

OpenStack has "Metadata Service" which provides the mechanism for retrieving instance information from the instance guest OS. By accessing the special URL under "http://169.254.169.254/latest/meta-data", you can retrieve instance information such as am instance type, security groups and assigned IP addresses. You can also add custom metadata in the "Key-Value" form.

There is also a special metadata called "user-data". If you specify a text file as uesr-data when creating a new instance, the "cloud-init" agent running in the guest OS will receive it, and do some startup configuration according to its contents. Typically, you can use a script file as user-data which will be executed by cloud-init to install application packages on startup.

Compute Engine: Metadata Server

Compute Engine has "Metadata Server" which provides the mechanism for retrieving instance and project information from the instance guest OS. One of the following URLs are used to access metadata.

Metadata Server provides "Instance metadata" and "Project metadata". Instance metadata is associated to each instance providing information specific to the instance whereas Project metadata is associated to the project and shared by all instances in the project. You can add custom metadata for both Instance metadata and Project metadata in the "Key-Value" form.

There is also a special metadata called "startup-script" and "shutdown-scripts". They are executed when you start or shutdown the instance respectively. Different from OpenStack's user-data, startup-script is executed every time you restart the instance. These are handled by the agent included in "compute-image-packages" which is preinstalled in the official template images.

Reference:

Agents in guest OS

OpenStack: cloud-init

The agent package called "cloud-init" is preinstalled in the standard guest OS images of OpenStack. It handles the initial configurations, at the first boot time, such as extending the root filesystem space, storing a SSH public key and executing the script provided as user-data.

Compute Engine: compute-image-packages

The agent package called "compute-image-packages" is preinstalled in the standard guest OS images of Compute Engine. It handles the initial configurations at the first boot time, and also handles dynamic system configuration while the guest OS is running.

The dynamic system configuration includes adding new SSH public keys and changing network configurations required for HTTP load balancing for example. You can generate and add a new SSH key through Cloud Console or gcloud command after launching an instance. This is done through the agent running on the guest OS as a daemon process.

As a side note, the agent uses Metadata Server for the dynamic configuration. Compute Engine's Metadata Server provides a mechanism to notify the agent about metadata updates, and the agent is triggered with the metadata updates.

Reference:

Accessing other services from applications

In the standard guest OS images of Compute Engine, SDK (including gcloud command) is preinstalled and you can use them with the "Service Account" privilege to access other services of GCP. Through the IAM mechanism, access control is enforced per instance. For example, read-only authority for Cloud Storage is assigned to an instance by default. If you want your application running in the instance to store data in Cloud Storage, you need to assign the read-write authority to the instance. With this mechanism, you don't have to setup passwords or credential codes for applications running in the instance by hands.

Reference:

What's next?

I would give a sample architecture for a typical 3tier web application both on OpenStack and GCP.

enakai00.hatenablog.com

OpenStackユーザーのためのGoogle Cloud Platform入門(パート3)

前置き

これは、GCPの公式文書ではありません。公式ドキュメントについては、公式ホームページを参照ください。

Google Cloud Platform

実際に試してみたい方は、60日の無料トライアルをお試しください。(クレジットカードの登録が必要ですが、トライアル終了後は明示的に課金設定を行わない限り、勝手に課金されることはありませんので、ご安心ください。)

cloud.google.com

本記事のパート2はこちらです。

enakai00.hatenablog.com

パート3では、VMインスタンスに関連するコンポーネントとして、OpenStackのNova/CinderとGCPのCompute Engineを比較します。

インスタンスサイズ

OpenStackでは、インスタンスのサイズ(インスタンスに割り当てる仮想CPUの個数とメモリー容量)は、「インスタンスタイプ」から選択します。インスタンスタイプの内容は、システム管理者によって定義されており、一般の利用者が新しいインスタンスタイプを追加することはできません。

一方、Compute Engineでは、インスタンスのサイズは、「マシンタイプ」として定義されています。インスタンスの起動時にマシンタイプを選択するところはOpenStackと同じですが、必要な際は、CPUの個数とメモリー容量を個別に指定して「カスタムマシンタイプ」でインスタンスを起動することも可能です。

(参考)
Machine Types
Creating an Instance with a Custom Machine Type

ストレージオプション

OpenStackのEphemeral DiskとCinder Volume

 OpenStackでは、インスタンスに接続するディスクの種類として、「Ephemeral Disk」と「Cinder Volume」が選択できます。元々は、OSをインストールしたシステム領域にはEphemeral Diskを利用して、永続データの保存領域としてCinder Volumeを利用するという使い方が標準的とされていました。しかしながら、この構成の場合は、Live Migrationができないなどの制限があるため、現在では、システム領域にもCinder Volumeを利用する事が多くなりました。

Ephemeral Diskを使用する場合は、Glanceが管理するテンプレートイメージの複製をコンピュートノードのローカルディスクにダウンロードした後に、これを用いてインスタンスを起動します。インスタンスを停止・破棄するとローカルディスク上のディスクイメージも同時に破棄されます。一方、Cinder Volumeの実体は、外部のストレージ装置に存在する永続的なディスク領域です。典型的な構成では、iSCSIプロトコルでコンピュートノードに接続した後に、これを用いてインスタンスを起動します。インスタンスを停止・破棄してもボリュームの実体はそのまま残りますので、他のインスタンスに再度、接続して利用することが可能です。

・Ephemeral DiskとCinder Volumeの違い

Ephemeral Diskは、ディスクイメージの実体がコンピュートノードのローカルディスクに配置されるため、ディスク性能が要求される場合に利用されることがあります。Cinder Volumeについては、性能要件の異なるストレージ装置を用意しておき、利用者がボリュームを作成するストレージ装置を選択することも可能です。

その他には、インスタンスのゲストOSから、OpenStack Swiftが提供するオブジェクトストレージを使用することも可能です。

Compute Engineのストレージオプション

Compute Engineのインスタンスに接続するディスクは、「Persistent Disk」と呼ばれる永続的なディスク領域が基本となります。OpenStackと同様に、OSをインストールしたシステム領域に加えて、永続データの保存領域として追加のディスクを接続することも可能です。ディスクへの書き込み時は、自動的に暗号化の処理が行われるようになっています。1本のディスクは最大64TBまで拡張可能ですが、インスタンスのサイズによって、実際に接続できる最大容量が制限されています。

また、高い性能要件が求められる場合は、ローカル接続のSSDを使用することもできます。357GBのSSDを8本接続することで、最大3TBの容量が使用できます。また、ローカルSSDを接続している場合でもLive Migrationが可能です。ただし、ホスト間でSSDの内容のコピーが行われるため、Live Migrationの実行中は、ディスクアクセス性能が一時的に低下します。

その他には、インスタンスのゲストOSから、Cloud Storageが提供するオブジェクトストレージを使用することも可能です。

(参考)
Storage Options

メタデータ機能

OpenStackのメタデータサービス

OpenStackでは、「メタデータサービス」を利用することにより、インスタンス内部のゲストOSから、インスタンスに固有の情報を取得することができます。具体的には、「http://169.254.169.254/latest/meta-data/」以下のURLにHTTPでアクセスすることにより、対応する情報が取得されます。インスタンスタイプ、セキュリティグループ、IPアドレスなどの情報が取得可能です。その他には、独自のメタデータを「Key-Value」形式で付与することもできます。

その他に、「user-data」と呼ばれる特別なメタデータがあります。インスタンス作成時にuser-dataにテキストファイルを与えると、ゲストOSの初回起動時に「cloud-init」と呼ばれるエージェントがこれを受け取って、ゲストOSの初期設定に利用します。例えば、スクリプトファイルを与えると、cloud-initによって自動的に実行されるので、アプリケーションのインストール処理などをスクリプトで自動化することができます。

Compute Engineのメタデータサーバー

Compute Engineでは、「メタデータサーバー」の機能により、インスタンス内部のゲストOSから、インスタンス固有の情報を取得することができます。以下のいずれかのURLを使用します。

http://metadata.google.internal/computeMetadata/v1/
http://metadata/computeMetadata/v1/
http://169.254.169.254/computeMetadata/v1/

提供されるメタデータには、インスタンスに固有の「Instance metadata」と、インスタンスが所属するプロジェクトの情報を提供する「Project metadata」があります。Instance metadataとProject metadataのそれぞれについて、独自のメタデータを「Key-Value」形式で付与することも可能です。

特に「startup-script」と呼ばれるメタデータに任意のスクリプトファイルを与えると、ゲストOSの起動時に「compute-image-packages」が提供するエージェントによって自動的に実行されるので、アプリケーションのインストール処理などをスクリプトで自動化することができます。OpenStackのuser-dataと異なり、startup-scriptは、インスタンスを再起動した際にも実行されます。また、インスタンスを停止する際に実行される「shutdown-script」を利用することも可能です。

(参考)
Storing and Retrieving Instance Metadata

ゲストOSで動作するエージェント

OpenStackのcloud-init

OpenStackでは、ゲストOSにcloud-initと呼ばれるエージェントをインストールすることにより、初回起動時の初期設定を行います。これには、ルートファイルシステムの拡張、SSH認証鍵の設定、user-dataの実行などが含まれます。

Compute Engineのcompute-image-packages

Compute Engineでは、compute-image-packagesが提供するエージェント群をインストールすることにより、初回起動時の初期設定に加えて、ゲストOSが稼働中の動的な構成変更などを行います。初回起動時の初期設定は、OpenStackと同様に、ルートファイルシステムの拡張、SSH認証鍵の設定、startup-scriptの実行などが含まれます。

ゲストOSが稼働中の構成変更については、SSH認証鍵の追加設定やロードバランサー配下に組み込む際のネットワーク設定変更などがあります。Cloud Console、もしくは、gcloudコマンドを利用すると、稼働中のインスタンスに対して、新たなSSH認証鍵を生成して登録することが可能ですが、これは、ゲストOS内のエージェントを利用して設定作業が行われます。

なお、ゲストOSを外部から操作する際は、メタデータサーバーの機能が利用されます。Compute Engineのメタデータサーバーは、メタデータの更新をエージェントに通知する機能があり、メタデータの更新をトリガーにして、エージェントによる設定変更作業を行います。

(参考)
Scripts and tools for Google Compute Engine Linux images.

ゲストOS内から他のサービスへのアクセスについて

Compute EngineのゲストOSには、GCPの他のサービスにアクセスするためのSDK(gcloudコマンドなど)が事前に導入されており、「サービスアカウント」の権限によって、他のサービスを利用することができます。この時、IAMの機能により、サービスアカウントから利用可能なサービスの範囲がインスタンスごとに設定されます。たとえば、Cloud Storageに対しては、デフォルトでは、読み込み権のみが設定されます。したがって、Cloud Storageに書き込みを行う際は、Cloud Console、あるいは、gcloudコマンドを用いて、サービスアカウントに対するアクセス権限の変更を行う必要があります。これは、インスタンスごとに利用可能なサービスの範囲が制御されるようになっており、インスタンス上で許可されたサービスにアクセスする際は、パスワードやクレデンシャルコードの入力は不要になります。

(参考)
Creating and Enabling Service Accounts for Instances

次回予告

次回は、典型的な3層Webアプリケーションを構築する際に使用するコンポーネント(サービス)をOpenStackとGCPで比較したいと思います。

enakai00.hatenablog.com