めもめも

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

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

Introduction to Google Cloud Platform for OpenStackers (Part II)

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 I of this article series is here.

enakai00.hatenablog.com

In this part, I describe networking functionality of GCP compared with OpenStack Neutron.

Comparing network models

OpenStack Neutron

Using OpenStack Neutron, you can create a virtual router inside your project (tenant) which provides an independent private network. It's just like creating your home network. You can add virtual L2 switches behind the router and assign private IP subnets. The VM instances can communicate through the virtual router using private IPs.

If you want to expose VM instances to an external network, you can assign a floating IP to an instance. Floating IPs are a pool of global IP addresses secured for the project in advance. The virtual router provides the NAT operation between the floating IP and a private IP of the instance.

The Neutron's private network is transparent to Availability Zones since it's configured spanning over all Availability Zones in a Region. However, you cannot configure a virtual network spanning over multiple Regions. The virtual network is solely confined in a single Region, VM instances in different Regions need to communicate over an external network using floating IPs.

It's possible to create multiple virtual routers in a project. In this case, VM instances under different routers cannot communicate directly with private IPs. They need to communicate through an external network with floating IPs.

GCP Networking

You can define multiple "Networks" in your GCP project. The "Network" is something comparable to the virtual router in Neutron. But one important difference is that the virtual router connects all Regions through an internal network. (Please see diagrams in the following sections for more concrete images.)

In addition, there are two different types of GCP's "Network", that is, "Legacy network" and "Subnet network." Interestingly, Legacy network provides a single private subnet spanning all the Regions around the globe. You can think that the "Virtual Switch" in the following diagram corresponds to the virtual router in Neutron.

https://cloud.google.com/compute/images/subnetworks/no_subnetworks_1.svg

Looking back the history of network architecture, people have used subnets to manage network gears in different physical locations. It's not a hard requirement for the cloud network emulating subnets in the real world. In GCP networking, you can use the tag-based access control mechanism which is independent of the concept of subnets. Using Legacy network, you don't need to be bothered with subnet management any more without compromising the access control.

Having said that, ...

People still need subnets in some cases, currently, GCP uses Subnet network as default. You can create only Subnet networks from Cloud Console. You need to use gcloud command to create Legacy networks.

Subnet network has a similar concept to Neutron's virtual networks. You can create multiple subnets in each Region. However, totally different from Neutron, as all Regions are connected through an internal network, all subnets are routable each other over private IPs. You don't need to use global IPs nor the Internet for inter-region communication.

You can think that "Virtual Switch"s (corresponding to the virtual router of Neutron) are connected through the global internal network.

https://cloud.google.com/compute/images/subnetworks/subnetworks_1.svg

I will mention the GCP's internal network details in a later section.

Note that Legacy network and Subnet network are not something exclusive. Like creating multiple virtual routers in Neutron, you can create multiple "Networks", and you can mix both Legacy network and Subnet network. When you create a new project, there is a single "Network" named as "default". It has a subnet with /20 range named as "default" in each Region.

Finally, talking about global IPs, GCP provides "External IPs" as a pool of global IPs for each project. There are two types of External IP such as "Static" and "Ephemeral". The "Static" External IPs work similarly as Floating IP of Neutron. You can use them as a permanent resource. On the other hand, the "Ephemeral" ones are assigned automatically when you launch a new instance and there is no guarantee for permanent existence. In other words, when you stop and restart an instance, you may have a different global IP if you're using the "Ephemeral" one.

Firewall configuration

Neutron provides a concept of "Security Groups" for packet filtering mechanism. A Security Group contains a multiple ACLs independent of specific VM instances. Once you associate a Security Group to an instance, the ACLs are applied to it. Typically, you would define Security Groups corresponding to specific roles of instances such as web servers or DB servers. Since Neutron's virtual networks are defined in each Region, you also need to define Security Groups in each Region.

In GCP Networking, you define firewall rules in each Network which spans all Regions. It specifies a filtering rule using "rule" and "tags". "Tags" are arbitrary labels associated with instances as metadata. You can associate multiple tags to a single instance. On the other hand, "rule" is an ACL specifying an allowed packet flow using the following conditions.

  • Source: IP range, subnet, tags
  • Destination: tags

With this mechanism, you can separate "tags to specify instance roles" and "rules to specify ACL corresponding to roles". For example, once you define a rule allowing sending packets from any IP to "web-server" tag, you can add the "web-server" tag to any instances to allow TCP80 connection for them. When you define a rule without specifying tags, it allows the specified connection to all instances.

By the way, when you create a new project, the "default" network has the following predefined rules. Can you guess what kind of connections they allow? "10.128.0.0/9" is a subnet containing the underlying subnets in all Regions.

From top to bottom, it allows the following connections.

  • ICMP from any external source.
  • Any packets between all instances connected to the "default" network.
  • RDP from any external source.
  • SSH from any external source.

GCP's internal network

Google owns the global internal network to provide various services to external customers. The overall architecture is explained in the following web site.

GCP utilizes this global infrastructure to provide the dedicated global internal network. The connection to external networks are provided at multiple locations called "Edge Points of Presence (PoPs)" around the globe. When you connect to an instance running on GCP from your location, you would reach one of the PoPs at the optimum location, and be routed through the high bandwidth internal network. In addition, since each PoP provides the contents caching mechanism, you can leverage it without any special treatment if you provide external web services from App Engine or Compute Engine on GCP thorough the global load balancer service.

There are some network providers who offer dedicated network facility to connect your office network directly to GCP's network infrastructure. Please refer to the following web site for details.

cloud.google.com

What's next?

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

enakai00.hatenablog.com

Introduction to Google Cloud Platform for OpenStackers (Part I)

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

GCP Basics

Google Cloud Platform provides various computing resources as a cloud service on top of Google's core infrastructure. It has several categories such as Compute, Storage and Bigdata. They offer the following core services in addition to other interesting services for Bigdata processing and analysis.

Compute
Service Description
App Engine Runtime environment for scale-out Web applications.
Compute Engine Runtime environment for virtual machines.
Container Engine Runtime environment for container application based on Kubernetes
Cloud Functions Runtime environment for asynchronous event driven functions.
Networking Common network infrastructure for all cloud services.
Storage
Service Description
Bigtable Distributed Key-Value store with HBase compatible API
Cloud SQL Managed service for MySQL database
Cloud Datastore NoSQL document database
Cloud Storage Object storage service

It also provides a common functionality for IAM (Identity & Access Management). You can use the following tools to interact with these services.

  • REST API
  • SDK (Command line interface tools such as the gcloud command.)
  • Google Cloud Console (Web portal)

The following shows a rough comparison with OpenStack's major components in terms of their functionalities.

OpenStack GCP
Keystone IAM
Horizon Cloud Console
Nova, Glance, Cinder Compute Engine
Neutron Networking
Swift Cloud Storage

Physical locations - Regions and Zones

OpenStack

When deploying OpenStack clusters in multiple locations, a single cluster managed with a dedicated controller is specified as "Region." You can define multiple "Availability Zones" inside a Region so that you can group together physical resources such as compute nodes and storage boxes. It depends on the infrastructure design how you split resources with Availability Zones. Typically, you would split them in the unit of racks or datacenter floors.

However, you need to ensure that you have a reasonable network bandwidth between Availability Zones. The best practice tells you that you'd better consolidate a single cluster (i.e. physical resources for a single Region) into a single data center to avoid problems caused by a lack of sufficient network bandwidth.

GCP

GCP also has a concept of "Regions" and "Zones" which allows users to manage geographical locations and failure zones of service resources.
. At the time of writing (July, 2016) there are four Regions around the globe, and each of them has multiple Zones. There is a more detailed description in the following official web site.

https://cloud.google.com/compute/images/zones_diagram.svg
Inside a Region, all Zones are connected with a dedicated internal network providing a bandwidth and latency comparable to one within a data center. It means you can safely deploy a (traditional tightly coupled) cluster application over multiple zones to achieve a high availability across multiple failure zones.

In addition, there has been an announcement about a plan for more Regions in coming years.

For some managed services like Bigtable and Cloud Storage, there are some patterns how you could specify the Regions and Zones to be used. Please refer to the following documents for details.

cloud.google.com

What's next?

In Part2, I'll give you a comparison between OpenStack Neutron and GCP's Networking service.

Here's Part2 now.!

enakai00.hatenablog.com