AWS Partner SA ブログ

[ESP] DRBD/Heartbeat/Pacemaker/Corosync/DRBD Proxy(株式会社サードウェア)

PSA酒徳です。クラスターウェア週刊2日目は、株式会社サードウェア秋山様にDRBDを使ったクラスタリングソリューションをご紹介頂きます。

会社名: 株式会社サードウェア

製品 / ソリューション名:

Linbitクラスタスタック・サポート(DRBD/Heartbeat/Pacemaker/Corosync/DRBD Proxy)
AZ間 HAソリューション
Region間データ転送バックアップソリューション
ローカルデータセンターからAWSへのバックアップソリューション

会社 / 製品ロゴ:

 

製品/ソリューション概要:

・AZ間HAソリューション（VIP/EIP型）

 

AZ間HAソリューション（VIP/EIP型）

DRBD/Hearbeat/Pacemaker/Corosyncを活用し、AWS AZを跨ぐ形でLinuxサーバーをHA化します。Route Tableを使って切り替える形でのVIPを活用する方法、EIPを活用する方法の2種類をサポートいたします。

参考資料
Amazon EC2環境におけるLinux-HA　Apacheクラスタ（VIP編）環境構築手順ガイド (RT+VIP)
Amazon EC2™環境におけるLinux-HAサイボウズOfficeクラスタ構築手順書　(EIP)

 

・Region間データ転送（バックアップ）

 

異なるregion間でデータをリアルタイムレプリケーション（転送）する事でデータの堅牢性を高レベルに保ちます。DRBD専用に開発されたデータの圧縮・高速転送用ツールとなるDRBD Proxyを利用する事で安定したデータの転送が可能になります。

 

・既存データセンター（Corporate data center）からAWSへのバックアップ

既存でご利用をいただいているデータセンターのデータをAWS上にリモートバックアップする事で災害時も運用を止めずにビジネスを継続する事が出来ます。

 

DRBDソフトウェアの特徴

豊富な利用実績で安心

利用実績20万セット(開発元推定値)以上の環境で利用されている安定したソフトウェアです。

大容量データレプリケーションをサポート

DRBDは最大1 PB (ペタバイト)のレプリケーションをサポートし、さらに複数セットのレプリケーションを同時に実行できます。

高パフォーマンス

SSD等の高速半導体ストレージに対する最適化。高速半導体ストレージ利用時でも10%～15%程度の同期オーバーヘッドしか発生しないため、高速半導体ストレージのメリットを十分にご享受いただけます。

長期サポート

ミッションクリティカルな用途で長期間安心してお使いいただくために、現行バージョンについて最長2022年までのサポートをコミットしています。*3

*3有償保守契約下のお客様のみへのサービスです。コミュニティー版では上記サポートのコミットはありません。

詳細はサポート内容の違い（コミュニティー版との違い　https://www.3ware.co.jp/product/linbit-cluster-support/different    ）をご確認ください。

 

DRBD Proxy　ソフトウェア 特徴の特徴

DRBD ProxyはDRBDのリアルタイム・データレプリケーション機能を広域ネットワーク（WAN）上で効率的に実行できるように拡張するソフトウェアです。回線速度や回線品質が保証されないインターネット回線経由でも、DRBDプロトコルに特化したパケット圧縮と、メモリーバッファによる転送アクセラレーションを行い、地理的に離れた拠点間でのデータレプリケーションを実現します。

仕様上1 PB (ペタバイト)のディスク領域(パーティションまたは論理ボリューム)のデータをレプリケートできます。国内でも、数百GB (ギガバイト)〜350TB (テラバイト)のデータベースやファイルサーバーなどの遠隔バックアップに幅広く使われています。

DRBD Proxyを使った場合、1回のMySQLベンチマークの実行所要時間は、帯域幅が限られ遅延が大きい場合でも、LAN上のレプリケーションとほぼ同等になります。このような優れたアクセラレーション効果により、遠距離のリアルタイム・データレプリケーションを実用的にお使いいただけます。

DRBD Proxyの主な実績

・350TBのファイルサーバーのデータを約350km離れた本社・データセンター間で遠隔バックアップ
・東京と大阪のそれぞれ8TBのファイルサーバーのデータを相互に遠隔バックアップ(総量16TB)
・関西-九州間でリレーショナルデータベースのトランザクションをリアルタイムに遠隔レプリケート

 

システム要件/利用するAWSサービス:

対応OS
DRBDはLinux OS上で動作するソフトウェアです。現在LINBITクラスタスタック・サポート向けの認定バイナリパッケージが提供されているディストリビューションは以下のとおりです。

• Red Hat Enterprise Linux 5、6、7※
• SUSE Linux Enterprise Server 10、11
• Oracle Linux 6.3
• Debian GNU/Linux 6.0、7.0
• CentOS 5、 6、 7
• Ubuntu Server Edition 10.04LTS、12.04LTS、14.04LTS
• XenServer 5, 6 (DRBD のみ)　

パッケージが提供されていなくても、ソースコードが公開されているため、Linuxディストリビューションであれば、コンパイルしてインストールすることができます。

※ Red Hat Enterprise Linuxの完全互換OSについてはお問い合わせください。

利用するAWSサービス
Amazon EBS/Elastic IP（EPI型の場合）/Route Table(VIP型の場合)

対応管理サービス（リソースエージェント）
https://www.3ware.co.jp/product/linbit-cluster-support/resource

費用:
https://www.3ware.co.jp/product/linbit-cluster-support/support

その他情報:
https://www.3ware.co.jp/product/linbit-cluster-support/summary

提供形態　BYOL

お問い合わせ先:
株式会社サードウェア
https://www.3ware.co.jp/   
03‐4530‐8670
[email protected]

 ------------------------------------------------- 
エコシステム ソリューション部
パートナー ソリューションアーキテクト
酒徳　知明

[ESP] ClusterPro(日本電気株式会社)

PSA酒徳です。今週はAWS上で稼働するクラスターウェアを3日間に渡りご紹介させて頂きたいと思います。本日はその第一弾として日本電気株式会社「CLUSTERPRO X」のご紹介になります。

会社名:  日本電気株式会社

製品 / ソリューション名: HAクラスタリングソフトウェア「CLUSTERPRO X」 (クラスタープロ エックス)

会社 / 製品ロゴ:

システム構成図:

製品/ソリューション概要:

HAクラスタリングソフトウェア「CLUSTERPRO X」はシステム障害の復旧のみならず、ユーザの利用環境のメンテナンスや災害対策用途でもご利用いただけます。アマゾン ウェブ サービス（以下AWS）には、2012年より対応し、既に多数の実績がございます。特に、毎月開催している技術認定セミナーでは、AWSを使用した本ソリューションのデモを実施しており受講者の皆様に好評をいただいております。（コース内容については変更になる場合もあります。技術認定セミナーの詳細については、次のURLよりご覧ください。
http://fcc.express.nec.co.jp/clpnintei/

 

さて、今回のソリューションの特長ですが、オンプレミスでのHAクラスタとは異なるAWSならではの方法でHAクラスタを構築した点にあります。

■AWSでHAクラスタを構築する際の課題１：共有ストレージが使用できない。

オンプレミス環境では、2台の業務サーバ（以下、クラスタノード）が共有ストレージを用いデータを排他的に共有する（現用系のみから利用する）構成が一般的ですが、その構成をVPC上ではそのまま実現できません。確かに、S3などでファイルを共有することも可能ですが、データベースなどで用いる大きなデータをS3で共有するのは現実的とは言えません。更に完全な排他性を維持できません。そこで、EC2よりEBSの利用を考えますが次のような課題があります。

■AWSでHAクラスタを構築する際の課題２：EBSはAvailability Zoneを跨げない。

EBSを共有ストレージに見立てて使用することもアイディアとしては悪くありませんが、EBSはAvailability Zoneを跨げないので、Availability Zone全体の問題が発生した際に対処できなくなるという問題があります。

■AWSでHAクラスタを構築する際の課題３：仮想IPアドレスが使用できない。

AWSでHAクラスタを構築する際は、ストレージの課題の他にアクセス経路の課題も発生します。オンプレミス環境では、クラスタノードに仮想IPアドレスを付けたり外したりすることで、クライアントはサーバへのアクセスを透過的に行うことができます。それには、RIPやARPを使ってクライアントやルータに仮想IPアドレスの付いたクライアントノードを認識させる必要がありますが、VPCはマルチキャストやブロードキャストをサポートしていないため、オンプレミス環境で使用していた仮想IPアドレスをAWSでは実現することができません。

 

□CLUSTERPROによる解決
前述の３つの課題をCLUSTERPROでは次のように解決しています。

「CLUSTERPROが持つミラーディスク型HAクラスタ機能の利用とスクリプト実行によるAWSのルートテーブルの変更」

CLUSTERPROでは、共有ディスク型HAクラスタの他、ミラーディスク型HAクラスタを構築することができます。ミラーディスク型HAクラスタとは、対となるクラスタノードにデータの複製を作成し、フェイルオーバーした際（クラスタノードを切り替える際）、その複製されたデータを利用する技術です。このデータを複製する技術はミラーリングと呼ばれ、CLUSTERPROでは、OSのファイルシステムより下位の層で動作させ、データはブロック単位で複製（同期）されています。そのため、ファイルの大きさや数に影響を受けずに、安定したパフォーマンスを発揮できます。このミラーディスク型HAクラスタを使うことで、Availability Zoneを跨いだMulti-AZ構成でのHAクラスタを構築することができます。

また、CLUSTERPROではフェイルオーバーの際、様々なスクリプトを実行することができます。例えば、上記の図で記したようにAWSのAPIを用いてVPCのルートテーブルを動的に切り替えることで仮想IPアドレスと同等のアクセス経路の変更を行うことができます。他にも、EIPを動的に付け替える方式もサポートしています。詳細については、下記の「AWS向けHAクラスタ構築ガイド」を公開し、サンプルスクリプトも無償で提供しています。

このようにして、CLUSTERPROを用いるとAWS上でHAクラスタ構築が行えます。

□災害対策（DR）用途にクロスリージョンでのHAクラス構成も組むことが可能

さらに、CLUSTERPROでは、リージョンを跨いだクロスリージョンでのHAクラス構成も組むことが可能です。災害対策（DR）や事業継続（BCP）で有用な手段です。

この場合、2つのリージョンのVPCをVPNでつないで構成しますが、ここでもアクセス経路の問題が発生します。この問題については、Route53のプライベートDNSを用いて解決します。この際もRoute53に対するスクリプトを記載する必要がありますが、サーバーワークス様のCLOUD AUTOMATORを用いるととても簡単に行うことができます。詳細については、サーバーワークス様のプレスリリースをご覧ください。

http://www.serverworks.co.jp/news/news20141126

CLUSTERPROは、CLUSTERPRO WORKS（クラスタープロワークス）というパートナー制度を通じ、サーバワークス様をはじめとした100社を超えるパートナーとの協業により、様々な業務ソフトウェアとの連携もございます。また、「クラウドではHAクラスタを構築したことの無いユーザ様」や「これからクラウドでHAクラスタ構築を実施するSE様、SIer様」に対して、様々なクラウドサービスの実施経験があるクラウドHAコンサルタントがサポートし、システム構築を支援する有償サービスも提供しています。

 

システム要件/利用するAWSサービス:
Windows2003以降、各種Linux
詳細は、ホームページをご覧ください。
http://jpn.nec.com/clusterpro/

AWSサービス
EC2,EBS,VPC

導入実績:
http://jpn.nec.com/clusterpro/case.html

費用:
http://jpn.nec.com/clusterpro/clp/product.html

その他情報:
製品URL　 http://jpn.nec.com/clusterpro/
AWS向けHAクラスタ構築ガイド　http://jpn.nec.com/clusterpro/clp/cloud/cloud_sysrep.html

お問い合わせ先:
製品に関するお問い合わせ：　[email protected]
クラウドHAコンサルに関するお問い合わせ：　[email protected]
お問い合わせいただいた個人情報は、「NEC個人情報保護ポリシー」
http://jpn.nec.com/site/privacy/index.html に基づき適切な利用/管理/保護に努めます。

 ------------------------------------------------- 
エコシステム ソリューション部
パートナー ソリューションアーキテクト
酒徳　知明

『エンタープライズAWS導入ガイド』最新版がリリースされました！

エンタープライズAWS導入ガイドは、Amazon Partner Network（APN）のメンバーであるアクセンチュア様、アビームコンサルティング様、伊藤忠テクノソリューションズ様、サーバーワークス様、日本ユニシス様、日立製作所様6社が各社の知見を持ち寄り、エンタープライズシステムで、アマゾンウェブサービス(AWS)をいかに活用するかに焦点を当て共同執筆したガイドブックになります。

AWS Summit 2014でもパネルディスカッションという形で紹介させて頂き、現在、多くのユーザー様にご利用されています。(http://codezine.jp/article/detail/7918) 

2014年4月の第一版リリース以降もAWSの技術革新は日々続いており、最新の情報をお届けするために6社様が導入ガイドの更新を実施し、本日最新版(第1.1版 2014.12.22)の公開を致しましたのでお知らせします。

 

第１部　AWSによるエンタープライズシステムの幕開け    5

第１章 はじめに         5
    第１節         目的    5
    第２節         背景・トレンド  6
    第３節         AWS概要       7
    第４節         AWSクラウドの付加価値      8
    第５節         典型的なエンタープライズシステムの定義 10
第２章 AWSサービスの概要            11

第２部　AWSによるエンタープライズシステム実現の勘所            15

第３章 エンタープライズシステム構成例     15
    第１節         重要度別のシステム構成例 15
        第１項     システムに求められる重要度分類   15
        第２項     ノンプライムシステムのシステム構成例      16
        第３項     プライムシステムのシステム構成例            18
        第４項     ミッションクリティカルシステムのシステム構成例   20
    第２節         システムの広がりを考慮したシステム構成例         22
        第１項     ハイブリッドシステムのシステム構成例      22
        第２項     海外拠点グローバルシステム連携のシステム構成例       24
    第３節         ユースケースごとのシステム構成例           26
        第１項     SAPを用いた基幹系システムのシステム構成例   26
        第２項     情報系システムのシステム構成例  28 

第４章 システム・運用要件   30
    第１節         基本サービス要件     31
    第２節         可用性／信頼性要件            33
    第３節         性能/拡張性要件       35
    第４節         セキュリティ要件        38
    第５節         運用要件        42
    第６節         コンプライアンス要件            44
    第７節         ベンダー要件 47 

第５章 移行    48
    第１節         データ移行     49
    第２節         サーバー移行            50
    第３節         ネットワーク移行        51 

第６章 調達    54
    第１節         予算管理        54
    第２節         コストモデル   54
    第３節         サイジング      55
        第１項     オンプレミスでのサイジングの考え方          55
        第２項     定期的なサイジング  56
    第４節         見積もり          57
        第１項     企業のITコストにおけるAWS利用料の位置づけ 57
        第２項     簡易見積ツールと見積もりのポイント          57
    第５節         契約    59
        第１項     契約上のポイント       59
        第２項     契約モデル    60
        第３項     SLA     61

 

APNパートナー様にご用意頂いた下記リンクから、無料にてダウンロード頂く事が可能です。

• アクセンチュア株式会社: 
  http://itpro.nikkeibp.co.jp/article/ActiveWP/20140513/556422/
• アビームコンサルティング株式会社: 
  http://jp.abeam.com/collaterals/eaws_implementation_guide.html

• 伊藤忠テクノソリューションズ株式会社:
   http://www.ctc-g.co.jp/solutions/ccoa/05.html
  
• 株式会社サーバーワークス: 
  http://www.serverworks.co.jp/aws_guide

• 日本ユニシス株式会社: 
  http://www.unisys.co.jp/services/ict/uselfcloud/

• 株式会社日立製作所: 
  http://www.hitachi.co.jp/products/it/harmonious/cloud/service/aws/index.html

【エンタープライズAWS導入ガイドの構成】

• エンタープライズAWS導入ガイド 第1.1版(2014.12.22)
• 付録．第４章システム・運用要件回答（詳細）

非常に読み応えがあり、役に立つ情報が満載です。是非、最新版を入手して一読頂ければと思います。

----------------------
エコシステムソリューション部 部長
パートナーソリューションアーキテクト
松本 大樹

[ESP] JP1のご紹介～AWS運用管理フォーカスセミナー～

PSA酒徳です。

今回はJP1のご紹介になります。オンプレミスの運用管理において実績十分のJP1ですが、AWSにも対応して頂いております。日立製作所　宮本様にJP1を使ったAWS運用についてご紹介頂きます。

製品 / ソリューション名:JP1

 

会社名: 株式会社 日立製作所

 

システム構成図

製品/ソリューション概要：

■JP1の概要

JP1は、ITシステムの安定稼働を支援する統合システム運用管理ソフトウェアです。日立が長年培ってきたシステム運用管理の技術・ノウハウを幅広く提供し、お客さまのシステム運用を統合的に支援します。

▼統合システム運用管理 JP1
http://www.hitachi.co.jp/Prod/comp/soft1/jp1/

▼JP1のコンセプトについてはこちら
http://www.hitachi.co.jp/Prod/comp/soft1/jp1/product/concept/index.html

■AWSでのJP1

JP1は、AWS環境、従来型システム(オンプレミス)と混在したシステム環境においても一元管理し、効率的な運用管理を実現します。

★オートスケールに対応した監視設定の自動化

JP1は、負荷に応じてサーバが増減するオートスケールに対応したシステムでも、自動的に監視運用が継続でき、柔軟性と安定稼働の両立を実現します。

▼詳細はこちら
http://www.hitachi.co.jp/Prod/comp/soft1/jp1/topics/cloud_service/index.html#cs01

★AWS環境の稼働監視強化

AWS環境において、EC2はもちろんAWS固有の管理情報も含めて、JP1で業務視点での監視ができます（Amazon CloudWatchとの連携機能により実現）。従来システムの稼働状況と合わせて一元管理することができます。

▼詳細はこちら
http://www.hitachi.co.jp/Prod/comp/soft1/jp1/topics/cloud_service/index.html#cs02

★AWS環境における従量課金制での運用コスト最適化

　オンデマンド・ミドルウェアサービス for AWS(ODM for AWS)は、日立ミドルウェア製品とそのサポートサービスを使った分の料金で利用できるAWS向け従量課金サービスです。ODM for AWSにより、オンプレミスでは難しい「短期利用」「スモールスタート」「ピーク時対応」が可能になります。案件増加に合わせ、対応できるJP1製品を拡大しています。

▼詳細はこちら
http://www.hitachi.co.jp/Prod/comp/soft1/jp1/topics/cloud_service/index.html#cs03

導入実績：

製造業A社様

ERPシステム更改にあたり、全システムをオンプレミスからAWSへ移行

▼その他の導入事例はこちら
http://www.hitachi.co.jp/Prod/comp/soft1/jp1/search/gyoshubetsu_index.html

システム要件：

▼対応OS(Windows®, Linux®)
http://www.hitachi.co.jp/Prod/comp/soft1/jp1/product/environment/cloud/pdf/jp1v10_cloud_platform_os.pdf

費用：

▼ご利用料金についてのご案内
http://www.hitachi.co.jp/Prod/comp/soft1/odm/price/index.html

※その他のJP1製品につきましては、下記よりお問い合わせください。

その他の情報：

▼プログラムプロダクトテクニカルサービス
http://www.hitachi.co.jp/Prod/comp/soft1/technical/index.html

お問い合わせ先：

HMCC(日立オープンミドルウェア問い合わせセンター)

▼お気軽にお問い合わせください。
http://www.hitachi.co.jp/Prod/comp/soft1/jp1/inquiry/index.html

◆商標に関する表記

・Windowsは,米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
・Linuxは，Linus Torvalds氏の日本およびその他の国における登録商標または商標です。
・その他記載の会社名、製品名は、それぞれの会社の商標または登録商標です。

 ------------------------------------------------- 
エコシステム ソリューション部
パートナー ソリューションアーキテクト
酒徳　知明

[ESP] Cloud Automator (サーバーワークス)

PSA松本です。今回はサーバーワークスの千葉様より、SaaSで提供している運用自動化サービスをご紹介頂きます。

製品 / ソリューション名: 

会社名:  
サーバーワークス

システム構成図:

 

 

製品 / ソリューション概要:

「Cloud Automator」はAmazon Web Services（AWS）の運用を自動化するサービスです。

AWSの運用に欠かせないバックアップ、インスタンスの起動 / 停止など、様々なオペレーションを自動化します。Cloud Automatorの利用によって、手動によるAWS運用の手間を軽減し、人為的ミスのない運用を実行することができますので、AWS運用時のTCO削減、運用品質の向上を両立し、AWSのメリットを最大限に引き出すことができます。

 

Cloud Automatorの利用シナリオ：

1. 業務時間外は開発用インスタンスを停止してコストを削減する

業務開始時間 / 終了時間に自動的にEC2インスタンスを起動/停止することでEC2の運用費用を削減。インスタンスはタグによる指定も可能なため、開発用のサーバーが後から増えた場合でも、適切なタグをつけることで同一ルールによる運用が可能。

 2. EBSボリューム / RDSインスタンスのスナップショット / EC2インスタンスのAMIを毎日取得する

 毎日EBSボリュームのスナップショット/RDSインスタンスのスナップショット/EC2インスタンスのAMIを作成し、任意の世代（最大50）数でローテーションすることが可能。ボリュームはタグによる指定も可能なため、後からボリュームが増えた場合でも、適切なタグをつけることでバックアップジョブを自動的に適用させることが可能。

 3.監視ツール等の外部サービスから「Cloud Automator」のジョブを実行する

HTTPリクエスト / SQSを利用してジョブを実行する機能（トリガー）を使い、監視ツールで障害を検知した場合に自動的にRoute53のゾーン情報を書き換えたり、オンプレミス環境とAWS環境を同一のRBA（RunBook Automation）で管理したりすることが可能。

4. Redshiftの起動・停止を自動化

クラウド型DWHとして人気のRedshiftを様々な条件（タイマーやSQS等）で停止・起動させることが可能。分析が必要な時間帯だけRedshiftを起動させたり、ETLツールと連動させてデータ取り込みバッチの時間帯だけRedshiftを起動し、取り込みが終わったら停止させるといった運用が可能。

 

これらのシナリオ以外にも、複数のジョブを連携することでより複雑なオペレーションを自動化することが可能です。

Cloud Automatorは、高い信頼性が求められるサービスのため、ジョブ管理にAWSが提供するマネージド型ワークフローサービス「Simple Workflow（SWF）」を全面的に採用しました。

ユーザーがジョブを登録したりログを確認するWebアプリケーションはHerokuで稼働させつつ、スケジューラー、ジョブを実行するWorkerといった高い信頼性が求められる心臓部にはSWF + OpsWorksの組み合わせを採用しています。

ユーザー(構成図左側：緑色の網掛け)は、『Webアプリケーション』へアクセスしジョブを作成することで、『Workerアプリケーション』にてSWFワークフローを起動します。

『Workerアプリケーション』は、作成されたジョブのパラメーターに従い、ユーザーのAWSリソース(構成図右側：緑色の網掛け)をAPI経由で操作します。 

『Workerアプリケーション』の実行環境は、OpsWorksで構成を管理しており、SWFドメイン毎に、Availability Zoneを跨いで2台以上のEC2インスタンスが稼働しています。EC2インスタンスでは、WorkflowWorkerとActivityWorkerのプロセスが6個ずつ起動しており、当該プロセスを内部監視/自動復旧することで高い可用性を実現しています。 

また、OpsWorksのLoadBase / TimeBaseオートスケール機能を活用することで、無駄なコストを掛けることなく『Workerアプリケーション』を常に最適な環境で稼働することを可能としています。

EC2インスタンス  / SWFのステータスはCloudWatchにて計測しており、意図せぬ動作をした場合は、SNSにて管理者へ通知が送られます。

 

 システム要件/利用するAWSサービス:

インターネットブラウザを持つOS
OpsWorks, SWF, EC2, S3, IAM,  VPC,  Route53, CloudWatch, SNS

  

導入実績:

丸紅株式会社様
http://www.serverworks.co.jp/news/news20140714 

ハンズラボ株式会社様
http://www.serverworks.co.jp/case/handslab

 

費用:

http://cloudautomator.com/#price

  

その他情報:

http://cloudautomator.com/

 

お問い合わせ先:

[email protected]

 ----------------------
エコシステム ソリューション部 部長
パートナー ソリューションアーキテクト
松本 大樹

AWS上のRHELのサポート体制とアップデートサーバー

PSA松本です。今回はRed Hatの平さんからの投稿です！

---------------

皆さん、こんにちは！
Red HatのPartner SA(Partner Solutions Architect: PSA) 平です。
Global OEM PartnerとしてAWSを担当しております。

 

 

 

Red HatはAWS誕生初期の頃から、テクノロジーパートナーとしてAWSに様々な形でテクノロジーを
提供してきました。AWS上でOS製品、ミドルウェア製品、ストレージ製品など利用可能です。
近年、エンタープライズ・ユースのワークロードのAWSへの移行が加速しており、さらに両社の間で
協業を進めております。やはり基幹システム向けのLinuxと言えば、Red Hatです。

 

 

RHELのサポートも、AWSサポートで万全！！

 

AWSマネジメントコンソールで、EC2インスタンス作成時にウィザードでリストの2番目として出てくるので、AWS上でRed Hat Enterprise Linux(RHEL)を利用可能だということはご存知の方も多いと思います。
また、AWSはワールドワイドでOEM契約先となっており、RHELの1次サポートもAWSサポートにて行うことができます。

 

 

AWS上でのRHELの利用形態と契約形態

 

通常のRHELは1年単位でのサブスクリプション契約で提供しておりますが、AWS上においては、1時間単位で利用可能できるHourly On-demandと、BYOS(Bring Your Own Subscription)で、既にご契約済みのサブスクリプションをAWS上へ持ち込むこともできます。※2 ※3

 

※2 持ち込めるサブスクリプションには制限があります。OEM版サブスクリプションは持ち込めません。
※3 持ち込む場合は、事前にCloud Accessという手続きが必要です。詳しくは次のURLをご参照下さい。
http://www.redhat.com/ja/technologies/cloud-computing/cloud-access

Hourly On-demandで提供されるRHELは、OEM版クラウド契約という扱いになっておりまして、AWSがエンドユーザーに提供する個数をカウントして何台でも提供することができます。

 

 

インスタンス起動時にレポジトリがすぐに使えるのは何故か

 

RHELのEC2インスタンスを起動すると、通常必要なシステム登録もなく yum コマンドでレポジトリが使えるので不思議に思う方も多いことでしょう。

通常のRHELは、subscription-manager コマンドもしくは rhn_register コマンドでシステム登録が必要です。 しかし、AWS上のRHELインスタンスには、事前にエンタイトルメント証明書がRPMパッケージ(rh-amazon-rhui-client) としてインストールされており、その証明書とインスタンスの固有情報を使ってAWSのリージョン内にあるアップデートサーバーから更新パッケージなどを取得することができます。したがって、このパッケージは絶対にアンインストールしないで下さい。

 

 

 

アップデートサーバーの仕組み

アップデートサーバーはRed Hat Update Infrastructure(RHUI)と呼ばれており、AWSがサーバーの運用しているため正確な配置は分かりかねますが、ホスト名から推察するに、世界各地のAWSのリージョンに複数セット設置されているようです。
アップデートサーバーは1日に何度か、Red Hat Contents Delivery Network (Red Hat CDN)からリポジトリを差分同期しており、バグ修正およびセキュリティ修正に追従して鮮度の高い状態が保たれています。 RPMパッケージをインストールする際に、バージョン名まで指定すると古いパッケージも入手可能です。なお、RHELの追加Add-on(High Availability Add-onや、Load Balancer Add-onなど)の購入が必要なレポジトリは、AWS上では提供されていませんのでご注意下さい。

 

 

アップデートサーバーは、このような仕組みになっておりますので、Amazon VPCやAWS Direct Connectで使用したい場合、VPC にInternet Gatewayを加えないとアップデートサーバーにアクセスすることができなくなり更新パッケージが適用できなくなります。

なお、Hourly On-demandのRHELは、subscription-managerで Red Hat に直接システム登録する権利はありません。きちんとRHELのインスタンスを運用したいのであれば、VPCにInternet Gatewayを加えて Security Groupにて適切なアクセスコントロールしてください。

 

2014年は、SSLの脆弱性や、Bashの脆弱性など影響度が高いセキュリティ課題がいくつかありました。更新パッケージの適用を怠り放置するとシステムが穴だらけになるだけではなく、情報漏洩やサイトの改竄など会社の信用を失墜する大きな問題へ発展します。

2015年は、基幹システムのAWS移行がさらに活発化し、それに伴ないAWS上でのRHELのニーズも、さらに高まることを予想しています。

 

今後ともAWS Partner SAブログなどで情報をご提供して行きますので、よろしくお願い致します。

 

[ESP] Hinemosのご紹介～AWS運用管理フォーカスセミナー～

Partner SA 酒徳です。今回はAWSのサービスを最大限にご活用頂き、AWSならではの運用管理を実現するHinemosについて、株式会社NTTデータ長妻様よりご紹介頂きます。

 

製品 / ソリューション名: Hinemos

会社名:  株式会社NTTデータ

システム構成図

・基本構成

　Hinemosはマネージャ、エージェント、クライアントの3つコンポーネントからなる統合運用管理ソフトウェアです。Hinemosはオンプレミス環境、仮想化環境、AWS環境の何れにインストールしてもAWS上のシステムを運用管理できます。

・シンプルな構成

AWSに構築したお客様システムの監視・性能管理、ジョブ管理、課金管理などの運用管理のため、同AWSアカウント上にHinemosを構築することができます。

・ハイブリッド統合運用管理①

既存のオンプレミス環境（データセンタ、プライベートクラウド環境）にHinemosを導入し、1台のHinemosだけで複数のAWS環境とオンプレミス環境を統合的に運用管理が可能です。

・ハイブリッド統合運用管理②

他のAWS環境のHinemosやオンプレミス環境のHinemosと連携して、統合的な監視・ジョブの連携が可能です。

・Hinemos HA on AWS

AWS環境上での監視やジョブ管理にて求められる高可用性を提供します。Hinemos HA on AWSはCloudFormationにより簡易に構築することが可能です（有償オプション）。

製品/ソリューション概要

・Hinemosの基本機能

Hinemosは、オープンソースの統合運用管理ソフトウェアです。監視や性能管理と合わせて、ジョブ管理機能を持つのが特徴です。業務カレンダ（運用日、メンテナンス日など）を定義し、より業務に密接した形でシステムのサービス監視や業務ジョブのコントロールができます。システムに障害が発生した際には、直ちにユーザに伝える手段も用意されており、画面表示の他にメール送信（SESにも対応）や簡易なコマンド実行、事前登録されたジョブフローの実行など、運用自動化に向けた機能が一通り揃っています。 

・AWS専用の運用管理

Hinemosクラウド管理オプションを導入することで、AWS上のシステム運用で必要となるクラウドならではの監視、コストコントロール、運用自動化を実現できます。

HinemosマネージャにAWSアカウントまたはIAMユーザのアクセスキー、シークレットキーを登録するだけで、AWS環境のシステム情報を自動的に取得し、直ぐに運用（監視・性能・ジョブ管理）が可能な状態になります。

特徴的な、AWS専用の運用管理機能は以下の通りです。

・AWS Health Dashboardの監視

AWS Health DashboardからAWSサービスの正常性を確認し、性能問題や障害発生した際に、直ちにユーザに通知できるほか、システムの障害イベントと一緒に履歴管理ができます。

・AWS CloudWatch連携

OSから取得できる性能値とCloudWatchから取得できる性能値を一緒に収集・閾値監視が出来ます。

・課金配賦管理

AWSアカウント単位、AWSサービス単位だけではなく、ユーザが運用を行っているシステム単位で課金管理ができます。特定のサーバの種類の単位や、日単位の料金の増分でアラートを上げたりと、細やかな課金管理ができます。

・AutoScaling対応

HinemosがEC2/EBSの追加、削除などの更新情報を自動的に取得し、運用管理リポジトリの情報に自動的に反映します。EC2インスタンスのタグからサーバの種類を識別し、追加されたインスタンスがWebサーバならWebサーバ専用の、APサーバならAPサーバ専用の監視やジョブを自動的に実行します。

・AWSリソースコントロールの自動化

EC2インスタンスの起動、停止、バックアップなどの操作をスケジューリングして実行し、クラウドのリソース制御による利用料金の削減と、運用自動化による人件費削減が可能になります。

 

システム要件/利用するAWSサービス:

・監視対象プラットフォーム

サーバ

　Red Hat Enterprise Linux、CentOS、Oracle Linux、Windows、Solaris、HP-UX、AIX

ハイパバイザ

　VMware ESXi、KVM、XenServer、Hyper-V、Oracle VM

クラウド

　Amazon Web Services、BizホスティングCloudn、Microsoft Azure、Managed Cloud Platform、BizホスティングEnterprise Cloud、IIJ GIO

・対応AWSサービス

　EC2, ELB, VPC, CloudWatch, CloudTrail, SQS, SES, Billing

 

導入実績:

・株式会社エクスジール様

　クラウド管理オプションをソーシャルゲームの人気タイトルで活用
　http://www.hinemos.info/hinemos/case/atomitech/1

・株式会社NTTドコモ様

　AWS上のシステムを一元管理
　http://www.hinemos.info/hinemos/case/008

・株式会社アールシーコア様

　運用担当者の業務負担を軽減と日々の運用コストの削減
　http://www.hinemos.info/hinemos/case/holontec/2

その他のHinemos導入実績は以下のサイトをご参照ください。

　Hinemos導入事例
　http://www.hinemos.info/hinemos/case

 

費用:

HinemosはオープンソースソフトウェアとしてSourceForge.JPに無償で公開しています。誰でも入手することができ、Hinemosの基本機能をご利用いただく範囲において費用は必要ありません。 

Hinemosプロジェクト
　http://sourceforge.jp/projects/hinemos/

Hinemosの保守サポート、有償オプション機能、各種ソリューションをHinemosパートナー企業より提供しております。詳細は、Hinemosパートナー各社までお問い合わせください。

　Hinemosパートナー一覧
　http://www.hinemos.info/partner/list

　Hinemosパートナーソリューション一覧
　http://www.hinemos.info/solution

 

その他情報:

・Hinemosクラウド管理オプション紹介ページ
　https://www.hinemos.info/option/cloud

・技術情報
　クラウド運用管理特集からクイックスタートガイド、SES連携、CloudTrail監視スクリプトなど各種技術情報を掲載しています。

　https://www.hinemos.info/technology

・【書籍】Hinemos 統合管理［実践］入門(2014/8/5発売)
　https://www.hinemos.info/news/softwaredesignplus_hinemos_20140805

 

お問い合わせ先:

Hinemosポータルサイトのお問い合わせフォームよりお問い合わせください。
Hinemosお問い合わせフォーム
　https://www.hinemos.info/contact 

------------------------------------------------- 
エコシステム ソリューション部
パートナー ソリューションアーキテクト
酒徳　知明

NECのルータIX2105からVPCのAWS DirectConnectに接続する

ソリューションアーキテクトの荒木です。

UNIVERGE IX2000/IX3000シリーズ : UNIVERGE IX2105 | NECを試すことができたのでVPCに対してAWS DirectConnect接続してみました。これは、前回のVPNで接続する方法と合わせてご覧ください。

こういったネットワーク機器にありがちなことですが、つながってしまえば呆気無いです。

私が試したIX2105のバージョンは8.8.22であるため、

  neighbor 169.254.100.1 receive-capability override

という記述が必要でした。これは、http://jpn.nec.com/univerge/ix/faq/bgp4.html#Q1-10にも案内がありますが、IPv4 Unicastとroute-refresh以外のBGP Capabilityを使えるルータが対向にいる場合に必要なパラメータです。現在のOSバージョンでは、override設定は必要ないようです。

順番が入れ替わりでしたが、今回の設定の前提は以下のとおりです。

• AWS側のIPアドレスは169.254.100.1 (指定できます。あるいは自動生成）
• AWS側のASNは10124 （東京リージョンでは常にこの番号です）
• AWS側のPasswordは123456 (指定できます。あるいは自動生成）
• IX2105側のIPアドレスは169.254.100.2 (指定できます。あるいは自動生成）
• IX2105側のASNは65001（指定してください）
• VLANは819（指定してください）

そして、IX2105での4ポートではDHCPを有効にして、VPC内の10.120.0.228で動作しているDNSサーバを使うようにしています。

今回、キモとなっているBGPの設定は下の7行だけです。

!
router bgp 65001
  neighbor 169.254.100.1 remote-as 10124
  neighbor 169.254.100.1 password 123456
  neighbor 169.254.100.1 timers 10 30
  neighbor 169.254.100.1 receive-capability override
  address-family ipv4 unicast
    originate-default always
!

IX2105がデフォルト経路を公報するように、

    originate-default always

を加えています。VPCのサブネットにはroute tableを設定できるため、route tableでインターネット向きはインターネットゲートウェイを使い、IX2105の下にあるオンプレ側ネットワークだけをVGWに向けることができます。VPCに対してIX2105からデフォルト経路を公報しても、インターネット向けトラフィックはオンプレに向かわせないことが簡単にできます。

実際に使った設定は次の通りです。前回のVPNで接続する方法と同じく初期化してから使っています。

! NEC Portable Internetwork Core Operating System Software
! IX Series IX2105 (magellan-sec) Software, Version 8.8.22, RELEASE SOFTWARE
! Compiled Jul 04-Wed-2012 14:18:46 JST #2
! Current time Dec 19-Fri-2014 15:15:48 JST
!
!
timezone +09 00
!
!
ip route default 169.254.100.1
ip dhcp enable
proxy-dns ip enable
proxy-dns server 10.120.0.228
!
!
ip dhcp profile lan1
  dns-server 192.168.1.1
!
router bgp 65001
  neighbor 169.254.100.1 remote-as 10124
  neighbor 169.254.100.1 password 123456
  neighbor 169.254.100.1 timers 10 30
  neighbor 169.254.100.1 receive-capability override
  address-family ipv4 unicast
    originate-default always
!
device GigaEthernet0
!
device GigaEthernet1
!
interface GigaEthernet0.0
  no ip address
  shutdown
!
interface GigaEthernet1.0
  ip address 192.168.1.1/24
  ip dhcp binding lan1
  no shutdown
!
interface GigaEthernet0.1
  encapsulation dot1q 819 tpid 8100
  auto-connect
  ip address 169.254.100.2/30
  no shutdown
!
interface Loopback0.0
  no ip address
!
interface Null0.0
  no ip address

ここで、IX2105から、VPC内のインスタンスにpingを打ってみることにします。環境は、AWS 専用線アクセス体験ラボからの値です。

Router(config)# ping 10.120.0.228 count 60
PING 169.254.100.2 > 10.120.0.228 56 data bytes
64 bytes from 10.120.0.228: icmp_seq=0 ttl=63 time=2.036 ms
..
64 bytes from 10.120.0.228: icmp_seq=59 ttl=63 time=1.997 ms
 
--- 10.120.0.228 ping statistics ---
60 packets transmitted, 60 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 1.962/2.129/2.394

RTTはあくまで参考ですが、東京都内（目黒にあるごく普通のオフィスビル）から、東京リージョン内の十分に独立性の確保された2つのアベイラビリティゾーン内のEC2インスタンスまでは、2mesc程度の遅延でつながることがわかりました。また、速度も900Mbps以上を実測できました。

閉域網でAWS DirectConnectを利用するためには、たったこれだけのシンプルな設定であることがおわかりになるかと思います。http://aws.typepad.com/sajp/2014/12/internet-routing.htmlの記事で、インターネットルーティングとトラフィックエンジニアリングについてお話しました。その場合と異なり、閉域網では、ネットワークの予期しない状態の変化はありません。そのため、このようなシンプルな設定で、安定したネットワークを経由して、AWSのサービスを利用できます。

----------------------
ソリューションアーキテクチャ部 部長
プリンシパルソリューションアーキテクト
荒木靖宏

2015年のAWS Partner SAブログについて

新年あけましておめでとうございます！Partner SAの松本です。
2015年も宜しくお願い申し上げます！

去年の12月から開始したAWS Partner SAブログですが、2015年から本格的に次々と情報提供をさせて頂こうと考えています。今後提供していくコンテンツとしては大きく下記のカテゴリになる予定です。

1. Ecosystem's Solution Pattern (ESP: エコシステム ソリューション パターン)
   このブログを開始しようと思ったキッカケでもありますが、AWS上で利用可能な製品やソリューションをまとめたサイトを作りたいと考えています。AWSを利用しようと思った時に、まずはこのサイトに来て頂くと求める製品やソリューションのより技術的な情報が見つけられるサイトを目指します。既にNRI様にmPLATのご紹介をして頂いていますが、他にも色々なパートナー様に執筆依頼をしていますので順次公開していきます。ゆくゆくは冊子や書籍にして配布したいとも考えています。
   
   
2. 技術関連情報
   SA荒木がNEC様のVPN Routerの記事を掲載していますが、PoC結果やアーキテクチャ解説などの技術中心なコンテンツです。AWSサービス自体の技術情報はAWS SAブログで掲載していきますが、ここではパートナー様の製品やソリューションを中心に掲載していきます。
   
   
3. 事例紹介
   AWSサービス自体の利用方法が普通でも、AWS上で稼働する製品やソリューションに先進性があったり、技術的に優れている、珍しい環境である、変わった利用方法である、など面白い事例があればこのブログにてご紹介させて頂こうと思っています。
   
   
4. AWSセミナー報告
   Partner SA酒徳が運用監視フォーカスセミナーの記事を掲載していますが、AWSとパートナー様との共催セミナーの様子などをお伝えします。
   
   
5. AWS Partner SAコラム
   AWS SAブログでERP on AWSの記事を私が投稿していますが、このような技術的でも事例でもないコラムのようなコンテンツです。本投稿のようなお知らせ的なポストも該当します。
   
   

昨年末から着々と準備を進めていましたが、2015年はこれらの情報をどんどん発信していきたいと考えていますので、引き続きご愛読をお願いします。 

またAPN(Amazon Partner Network)パートナーの皆様、上記カテゴリのいずれかにて是非執筆したい、という希望がありましたら遠慮なくご相談ください。出来る限り掲載出来るよう調整させて頂きます。我々と一緒に盛り立てて頂けると有難いです！

繰り返しになりますが、本ブログも含め、本年も宜しくお願い申し上げます。

----------------------
エコシステム ソリューション部 部長
パートナー ソリューションアーキテクト
松本 大樹