特集・ブログ
こんにちは。 てくさぽBLOGメンバーの村上です。 本ブログは、IBM Power Virtual Server をトライしてみた内容や感想をご紹介するブログです。 シリーズ化していますので、まずインデックスのご紹介をします。 インデックス ・IBM Power Virtual ServerでAIX環境を作ってみた ・IBM Power Virtual ServerのAIX環境にSWを導入してみた ← 本ページ ・IBM Power Virtual ServerのAIX環境を日本ロケールにしてみた ・IBM Power Virtual ServerのAIX環境をバックアップしてみた（Part.1） ・IBM Power Virtual ServerのAIX環境をバックアップしてみた（Part.2） ・IBM Power Virtual ServerのAIX環境とIBM Cloud x86環境を接続してみた 本ページは Power Virtual Server のAIXインスタンスを作成し終わったところからのご紹介となり、以下の③～⑤のセクションをご紹介します。 1) Power Virtual Server サービスの作成 2) AIXインスタンス 作成 3) AIXインスタンス 接続 4) ストレージ・ボリュームの反映 5) ソフトウェア導入 利用したクライアント端末（私のPC）は、Windows10 バージョン2004です。 3) AIXインスタンス接続 「2) AIXインスタンス作成」で作成したインスタンスに接続し、AIX環境にログインします。 ＜IBM Cloud からログアウトした状態からの説明です＞ ・IBM Cloud にログインし、画面左上の四本線「ナビゲーションメニュー」をクリックし、下部に表示される「リソース・リスト」をクリックします。 ・「Services」にPower Virtual Server のサービスが表示されますので、サービス名をクリックしてAIXインスタンス一覧の画面に移動します。 ※上記の出力例は、Power Virtual Server と同じタイミングで Watson Studio の検証も行っていたので、Watson Studioも「Services」に表示されています。 ・インスタンス名がリンクになっているので「AIX72-test」をクリックします。 インスタンスの詳細の画面に移動しました。 ・「サーバー詳細」の画面の右上にある「VMアクション」のプルダウンから「コンソールのオープン」を選択します。 ・AIXのコンソールが表示されます。 ・初期状態は、root ユーザでログインできてしまいます。 root ユーザでのログインはセキュリティ的に問題があるため、ログイン可能なAIXユーザを作成しパスワードを設定します。 そして、root ユーザではログインできないように設定変更しておきます。 ※ユーザ作成とroot ユーザの設定変更手順は省きます Power Virtual Server のポータルのコンソールは一定時間利用しないとタイムアウトになって接続が切れてしまいます。また、フォントや画面サイズを変更できないため出力が複数行に分かれてしまい使いにくいです。 そのため、次は、Power Virtual Serverのポータルのコンソールではなく、Tera Termや PuTTY などのターミナル・エミュレータ・ソフトウェアを利用してAIX環境にログインする方法を試します。 外からの接続になるので「外部IP」を利用します。 ・「ネットワーク・インターフェース」の項目に記載がある「外部IP」をコピーします。 以下はTeraTerm を使用した出力例です。 ・「ホスト」にコピーした外部IPをペーストし、プロトコルは「SSH」 を選択して「OK」をクリックします。 ・作成したユーザとユーザに設定したパスワードを入力し「OK」をクリックします。 外部IPを利用してAIX環境へのログインができました。 外部IPからの接続はパブリックネットワーク接続となり、イメージ図で表すと以下の赤線です。 ※上記の画像はIBMCloud柔らか層本(IBMサイト)から一部を抜粋しています。 （Version3.1_20210517 版） 4) ストレージ・ボリュームの反映 さて、この後、AIXインスタンスにソフトウェアを導入するので、ストレージ容量が足りなくなるかもしれません。ストレージ容量を増やしておきます。 「【やってみた】IBM Power Virtual Server でAIX環境を作ってみた」のブログで記載しましたが、AIXインスタンスは初期で20GBがrootvgにアサインされており、初期状態で既に15GB程度がシステムによって使用されているため、空き領域が5GB程度と少なくなっています。 インスタンス作成時に追加したストレージ・ボリューム「stg01」は、まだどの Volume Groupにも属しておらず、すぐに利用できる状態ではありません。 そのため、「stg01」をディスク領域として見えるように設定します。 ・「接続されているボリューム」の「stg01」を「ブート可能」にするため「オフ」の部分をクリックします。 ・確認画面になりますので「はい」をクリックします。 ブート可能設定に成功したメッセージが出力されます。 ・「ブート可能」のステータスが「オン」になっていることを確認します。 ・AIXインスタンスへログインし、物理ボリュームを認識させるコマンドを入力ます。 # cfgmgr ・設定前に現在のrootvg の容量を確認しておきます。 # lsvg rootvg 5,472MBの空きがあり、rootvg の容量は20GB(20,448MB)です。 ・ AIXインスタンスに認識されているPVを確認し、どのVGにも属していないhdisk0 を rootvg に割り当てます。 # lspv # extendvg rootvg hdisk0 ・再度「# lspv」コマンドを入力し、hdisk0がrootvgに追加されたことを確認します。 # lspv ・実際に容量が変更されたか確認します。 # lsvg rootvg 20GBだった rootvgに 10GBの「stg01」を追加したので、容量が30GB(30,656MB) になり、空き容量も15,680MBに増えました。 5) ソフトウェア導入 では、AIXインスタンスにソフトウェアを導入してみます。 簡単に導入できるコンパイラー「XL C/C++ v16.1(IBMサイト)」を入れることにしました。 XL C/C++導入作業前にやっておいたこと ・「システム前提条件」を読んでおきます ・XL C/C++ソフトウェアをダウンロードします。ソフトウェアは「60日間のFreeトライアル版」を利用しました。 ・XL C/C++ソフトウェアをAIX環境へ転送するツールをインストールしておきます。私はWinSCPをダウンロードしました。コマンドプロンプトでSFTP転送を実施してもOKです。 ・AIX環境上にXL C/C++ソフトウェアを展開して保管するためのファイルシステムを作成します（1GBの/work というファイルシステムを作成しました）。 ----------------------------------------------------------------------------------------------------------------------------------------------- ソフトウェア導入前のAIX環境の確認と設定を行います。 ・OSレベルの確認（サポートされているレベルか確認） # oslevel -s 7200-05-01-2038 ・必須ファイルセットの確認（ファイルセットが導入されているか確認） # lslpp -L bos.adt.include bos.adt.lib bos.adt.libm bos.loc.\* bos.rte bos.rte.libc ・導入先「/opt」ファイルシステムの拡張（500MBの空きが必要） # df -m /opt Filesystem MB blocks Free %Used Iused %Iused Mounted on /dev/hd10opt 384.00 41.54 90% 11471 52% /opt # chfs -a size=+500M /opt Filesystem size changed to 1835008 # df -m /opt Filesystem MB blocks Free %Used Iused %Iused Mounted on /dev/hd10opt 896.00 553.46 39% 11471 9% /opt 「/opt」ファイルシステムが41.54MBの空き容量だったので、500MB 拡張しました。 ・ローカルPCにダウンロードしておいたXL C/C++ソフトウェアを、AIX環境にアップロードします。アップロード先は事前に作成したファイルシステム/work です。 ファイル転送はWinSCPを利用して行いました。 ・AIX環境へのファイル転送が完了したら、AIX上で圧縮ファイルを解凍（展開）します。 # cd /work # ls -al total 564784 drwxrwxrwx 3 root system 256 Jan 25 03:51 . drwxr-xr-x 21 root system 4096 Jan 11 20:26 .. -rw-r--r-- 1 fumi grp01 289164548 Jan 07 00:05 IBM_XL_C_CPP_V16.1.0.0_AIX_EVAL.tar.Z drwxr-xr-x 2 root system 256 Jan 25 03:44 lost+found # uncompress IBM_XL_C_CPP_V16.1.0.0_AIX_EVAL.tar.Z # ls -al | grep XL -rw-r--r-- 1 fumi grp01 307650560 Jan 07 00:05 IBM_XL_C_CPP_V16.1.0.0_AIX_EVAL.tar # tar -xvf IBM_XL_C_CPP_V16.1.0.0_AIX_EVAL.tar これでソフトウェア導入前の事前準備が整いました。 あとはsmitで XL C/C++ を導入するだけです。 # cd /work/XLC_C/usr/sys # smit install_latest License agreement → YES 簡単に導入できました！ ストレージ・ボリュームを追加する手順が Power Virtual Server 独自ではありますが、オンプレミスの環境にストレージを追加することを想像したら・・Power Virtual Server の方が遥かにスピーディーで簡単です。 ところで、ソフトウェアを導入している時に気付いてはいたのですが、なんだか smit が使いにくいと思ったら、smit を英語表記のまま利用していました。久しぶりに smit を使ったのでロケールを日本語化することを忘れていました。 次のブログでは、言語環境（ロケール）を日本語にした手順をご紹介します。↓ 【やってみた】IBM Power Virtual Server のAIX環境を日本ロケールにしてみた 最後に Power Virtual Server のポータルWEB画面は使いやすいですが、あくまでも基盤(IaaS)を用意するまでの支援で、細かい設定はAIX環境内で実施しなくてはいけないことが分かりました。 そして、じっくり読んでいただいた方はお気付きかもしれませんが、XL C/C++ はソフトウェア保管先を含めても1.5GB程度の容量があれば導入できるので、ストレージ・ボリュームを拡張する必要がありませんでした・・。 せっかく追加したストレージ・ボリュームで、かつ、月400円程度(10GB)の課金ではありますが、不要なので削除しました。 必要ないリソースをすぐに削除できるのは、検証環境には大変ありがたい機能です。 ストレージ・ボリューム削除の手順は、また後日アップデートしたいなと思っています。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp 参考情報 IBM Power Virtual Server (製品情報)
こんにちは。てくさぽBLOGメンバーの山田です。 今年も「IBM Think」に参加しました。 昨年同様、IBM 独自の Watson Media を利用したデジタル開催でしたが、今年はアジア地域の時間帯に合わせた配信や機械翻訳に加え日本語同時通訳付きセッションもあり、年々参加しやすくなっています。 6月23日まで Think 2021 オンデマンドでセッションが視聴可能です。 「Think 2021 / Partner Experience at Think (IBMサイト)」（※IBM IDが必要となります） AIは、驚異的な量のデータの意味を理解できる唯一の方法 昨年4月に CEO に就任後初めて本格的に昨年度の成果や次の方針を伝える場となるクリシュナ氏の基調講演では、昨年から方針は変わらず、キー・テクノロジーであるハイブリッド・クラウドと AI へ更に注力し、より具体的な新しいソリューションとして以下の発表がありました。 IBM Watson Orchestrate AutoSQLのICP4Dへの組み込み Project CodeNet 昨年はバンキング・ヘルス・テレコムなどインダストリー色の強い発表が多くありましたが、今年は製品・サービスでの発表が色濃いとという印象でした。 クリシュナ氏のメッセージは、 "工場や機械に電力が供給されてきたように、あらゆるソフトウェアに AI を活用したインテリジェントが組み込まれていく、そして、依然としてスキルと専門知識の欠如が AI採用の障壁となっている状況に対する解決策を IBM は提供していく" というものでした。 エンドユーザの活動を自動化・省力化するソリューション 「IBM Watson Orchestrate」 IBM Watson Orchestrate は、IBM としては珍しい、エンドユーザの活動を自動化・省力化するインタラクティブな AIソリューションとして発表されました。 IBM が Watson として培った自然言語処理をベースとした AIテクノロジーにより、Salesforce、SAP、Workday などの一般的なビジネスアプリケーションや、チャット、カレンダー、メールなどの標準的なコラボレーションツールと連携可能で、最大50%の時間を取り戻すことができると言います。 会議スケジュール調整や承認などの日常業務で、AI が適切なアラートや分析結果を指示し、提案書作成などまさに個人の生産性を向上させることが具体的にイメージできるソリューションです。 これは、昨年の Think で発表された、汎用的に AI を適用し易い IT運用の自動化にフォーカスしたソリューションであった IBM Watson AIOps に対し、よりオフィスワークへ AI適用範囲を拡大し、営業や人事・オペレーションなど、日常業務のあらゆる自動化へ組み込めるテクノロジーを提供することで、よりパートナー様がイメージできるソリューションであると感じました。 図1：IBM Watson Orchestrate の概念 単なるチャットボットやデジタルアシスタンスとは違うことは、デモ*をみていただいた方がイメージが沸くと思います。 デモページ：「Watson Orchestrate Demo (IBMサイト)」 上記のデモは日本語字幕がありませんが、Thinkオンデマンドのセッションでは日本語字幕もありお勧めです。 Thinkオンデマンド セッション：「Think 2021 (IBMサイト)」 Watson Orchestrate は、OpenShiftベースの IBM Cloud Pak for Business Automation の一部として未だプレビュー中ですが、2021年度中に提供開始予定です。 速度は8倍、コストは半分。 データ管理ソリューション「AutoSQL」 次に、AIベースのソリューション「AutoSQL」の紹介がありました。 AI の採用を拡大する際の課題の1つは、機械学習に必要なデータの管理です。 企業は、貴重な洞察につながる可能性があるデータを大量に保有していますが、パブリッククラウド、プライベートクラウド、オンプレミスなど複数の場所に分散されており、実現には膨大な労力とコストが掛かるのが現実でした。 実際 Cloud Pak for Data においても、日本のお客様からの要望の多くがデータカタログ化にあり、IBM は Information Management領域での知見を惜しみなく IBM Cloud Pak for Data に取り込んでいます。 今回発表された AutoSQL は、自動的にデータカタログを作成する「AutoCatalog」と合わせて活用されることが想定されますが、この実現により複数の場所に保管されているデータウェアハウスやストリーミングデータなど、異なるデータソースを移動させることなく同じクエリーで検索することができる高性能のユニバーサルクエリエンジンとなります。 IBM からの発表によれば、「以前の8倍の速度で、他の比較されたデータウェアハウスのほぼ半分のコスト」の効果があるそうです。 AutoSQL は、IBM Cloud Pak for Data の機能追加として提供される予定です。 OpenShiftが大きな鍵を握る、オープンへのこだわり IBM President であるハースト氏は、"より企業が競争に打ち勝つにはイノベーションが必須であり、オープンであることは戦略的なビジネス上の決定である" と語りました。 オープンとはオープンソースという意味に閉じず、オープンスタンダード、オープン組織、オープンカルチャーなど多岐にわたりますが、多くの場所で実行可能な「オープン」の実現には Red Hat OpenShift のテクノロジーがベースとなると述べています。 これは、IBM のハイブリッド・マルチクラウド戦略や、フォーカス製品である IBM Cloud Paks からも明確にメッセージされていますし、IBM は引続き OpenShift を軸にテクノロジー戦略を推し進める事に何も変わりはなく、ブレのない姿勢を強く印象付けたメッセージだったと感じました。 そのほか、量子コンピューティング IBM Quantum用コンテナ・サービスである Qiskit Runtime のスピード向上や、AI にソースコードを学習させるための大規模データセットである Project CodeNet のリリースなどが発表されました。 特に、Project CodeNet により、コードの別言語への翻訳や異なるコード間の重複と類似性の特定が可能となり、レガシーなコードから最新のコードへの移行などが期待できます。 パートナー・エコシステムへの更なる投資 パートナー・エコシステムへの取り組みについても、大きな発表としてメッセージされました。 IBMテクノロジーをわかりやすくお客様に届けるには、パートナー様との協業・共創が必要で、10憶ドルもの投資を行うとの発表がありました。従来型の販売（再販）に加え、ビルド、サービスといったパートナータイプが追加され、ISV・CSP といったソリューションベンダーへの支援プログラムもより拡大されるようです。 特に、クラウドエンゲージメントファンド (CEF) は、お客様のワークロードをハイブリッドクラウド環境に移行するのに役立つ重要な技術リソースとパートナー向けのクラウドクレジットへの投資です。 Think後の日本IBM の中でもこの発表は強く認識されており、IBMグローバルとして、よりパートナー協業を強く推し進める姿勢であり、支援を強化する動きが活発化していると感じます。 さいごに 今までにない経験であったこの1年で、10年分のデジタル革命が起きたと言われています。 そしてこれからも続くであろうこの進化を、引き続きパートナーの皆様へお届けしていきたいと思います。
こんにちは。 てくさぽBLOGメンバーの村上です。 本ブログは、IBM Power Virtual Server をトライしてみた手順や感想をご紹介するブログです。 IBM Power Virtual Serverの 正式名称は、 IBM Power Virtual Server on IBM Cloud です。 （※2021/7 追記：正式名称に変更があり「on IBM Cloud」の部分が削除されました） 一般的には、PowerVS や Virtual Server と略されているようなのですが、似たような略称が他にもあって混同してしまいそうです・・。 そのため、本ブログではあまり略さずに、Power Virtual Server と記載します。 これから何回かに分けて ブログをアップしていきますので、まずインデックスのご紹介です。 インデックス ・IBM Power Virtual ServerでAIX環境を作ってみた ← 本ページ ・IBM Power Virtual ServerのAIX環境にSWを導入してみた ・IBM Power Virtual ServerのAIX環境を日本ロケールにしてみた ・IBM Power Virtual ServerのAIX環境をバックアップしてみた（Part.1） ・IBM Power Virtual ServerのAIX環境をバックアップしてみた（Part.2） ・IBM Power Virtual ServerのAIX環境とIBM Cloud x86環境を接続してみた 構築手順をご紹介する前に、Power Virtual Server を簡単にご説明します。 Power Virtual Server とは？ Power Virtual Server とは、IBM が提供するビジネス向けのクラウド 「IBM Cloud」とともに利用する、IBM の Power Systems を基盤として稼働しているLPAR環境です。 2021年5月現在、IBM Cloud には350個ものサービスがあるそうです。 以下に、 IBM Cloud と Power Virtual Server の歴史を簡単に纏めてみました。 2012年 IBMが買収したIaaS専門クラウド SoftLayer にてIaaSサービスを提供開始 2016年 SoftLayer に PaaS や SaaS のクラウドサービスを統合し、名称をBluemix に変更 2017年 Bluemix にAIの Watson が加わり、IBM Cloud としてブランド統合 2019年 Power Systems を基盤としたLPARサービス Power Virtual Server の提供開始 2020年 11月。東京データセンターにて 日本初、Power Virtual Server オープン IBM Cloud は、ここ10年も経たない間に、SoftLayer から Bluemix に。そして IBM Cloud と着々とパワーアップしています。 同様に、Power Virtual Server も新しい機能がどんどん追加されています。近い将来で、また大きな変化があるかもしれませんね。 それでは、本題に戻ります。 本ページでは、Power Virtual Server のAIX環境を作成するまでの手順を以下の2つのセクションに分けてご紹介します。 1) Power Virtual Server サービスの作成 2) AIXインスタンス 作成 利用したクライアント端末（私のPC）は、Windwos10 バージョン2004 です。 ちなみに、私は若かりし頃、基盤SEを数年間やっていましたが、遥か遠い昔のような気がする（本当に遠い昔）・・というくらいのSEスキルです。 1) Power Virtual Server サービスの作成 まずPower Virtual Server のサービスの作成から取り掛かります。サービスの作成は無償です。 ・IBM Cloud へログインします。IBM Cloud の ID をお持ちでない方は新規登録が必要です。 Blackの背景にWhite文字、IBMっぽいですね。 ・ログイン後、画面のバーにある「カタログ」をクリックします。 ・カタログの画面で Power Virtual Server を選択します。検索バーに「Power」と入力すると「Power Virtual Server」が一番先頭に出てきますので「Power Virtual Server 」を選択します。 自動でサービスの作成画面に変わります。 ・Power Virtual Server で利用する「ロケーション」として「東京04(tok04)」を選択します。 2021年5月現在、Power Virtual Server は13か所のロケーションから選択できます。 私の自宅（テレワーク中です）は東京なので、一番近いロケーション「東京04(tok04)」を選択してみました。 ちなみに、日本には東京以外で大阪にもロケーションがあります。大阪は「Osaka21(osa21) 」として2021年3月にオープンしました。 ・ロケーションの選択ができたら、画面右側の「サマリー」を確認し「作成」をクリックしてサービスを作成します。 以下のメッセージが出力されますが、まだサービスの作成は完了していません。 画面は「リソース・リスト」に自動で変わり、数分待つとリソース・リストの「Services」の欄に「Power Virtual Server 」が追加されました。 サービスの「状況」が「●アクティブ」になったら、いよいよ「インスタンス作成」に移ることができます。 アクティブになったサービスの「名前」の部分はリンク付きになっているのでクリックし、次の作業「AIXインスタンス作成」に進みます。 ＜参考情報＞ 「Power Virtual Server サービス」はリージョン（地理環境）毎に作成し、「Power Virtual Server サービス」の中に「Power Virtual Server インスタンス」を作ります。 「インスタンス」とは 「LPAR（区画）」のことです。Power Virtual Server のサービス内には、複数の インスタンス（AIX/IBM i/LinuxどれでもOK）を作成することができます。 異なるリージョンにインスタンスを作成したい場合は、別の Power Virtual Server サービスを作成する必要があります。 2) AIXインスタンス作成 「1) Power Virtual Server サービスの作成」でできた Power Virtual Server のサービス内にAIXインスタンスを作成します。 ・「インスタンスの作成」をクリックします。 ・「インスタンス名」に任意のインスタンス名を入力します。インスタンス名は「AIX72-test」にしました。作成するインスタンスは1つなので「インスタンスの数」が「1」になっていることを確認します。 「VMピン(IBMサイト)」は「オフ」のままでOKです。 VMピンは、IBM i の場合はオンにするか検討しますが、AIXではシリアルナンバー固定のソフトウェアは滅多にないので（今まで出会ったことがありません）、気にしなくて良さそうです。 ・SSH鍵の設定を行うため、「SSH鍵の作成」をクリックします。 ・Windows標準搭載の「コマンドプロンプト」をPC上で立ち上げ、「ssh-keygen」コマンドを利用してSSHの秘密鍵と公開鍵を作成します。 ※Windwos10の1803バージョンからsshクライアントが組み込まれ、特に設定を行わなくてもすぐsshを利用できるようになったようです。便利になりましたー。 # ssh-keygen -t rsa -b 4096 ・SSH秘密鍵「id_rsa」と公開鍵「id_rsa.pub」が作成できたことを、PC上で確認します。 ・「type」コマンドでSSH公開鍵の中身を表示し、公開鍵の文字列をコピーします。 # type . shh\id_rsa.pub AIXインスタンス作成のWEB画面に戻ります。 ・「鍵名」に任意のSSH鍵名を入力し（「my_ssh_pub」としました）、「公開鍵」には先ほどコピーした公開鍵の文字列をペーストします。 ・「SSH鍵の追加」をクリックします。 SSH鍵の追加ができたら、インスタンス設定WEB画面に戻ります。 ・先ほど追加したSSH鍵「my_ssh_pub」が「SSH鍵（オプション）」リストに追加されたので選択し「SSH鍵の作成」をクリックします。 以下のコメントが出力され、SSH鍵が正常に作成されました。 「ブート・イメージ」を選択します。 ・「オペレーティング・システム」は「AIX」を選択します。 ・「イメージ」は最新の「7200-05-01」を選択します。 ・「層」は「層3」を選択します。 「層」はストレージのタイプのことです。 層1：Tier 1 (NVMe-based flash storage) 層3：Tier 3 (SSD flash storage) で提供されています。 価格は、層1>層3 です。今回の検証ではディスク性能を求めませんので層3を選択しました。 Tier1とTier3は同一インスタンス内で同時に利用することはできず、インスタンス作成後にTierタイプを変更することはできません。インスタンス作成時の「層（Tier）」の選択は重要ですね。 「プロファイル」の設定画面です。 ・「マシンタイプ」は「S922」を選択します。 ・「プロセッサー」は3種類のタイプから選択できます。「上限なし共有」を選択します。 「マシンタイプ」は東京では「E980」or「S922」が選択可能です。同じリソースを選択した場合の価格は、E980＞S922となります。S922は14コアまで利用できるので、余程の大きな環境でない限り、S922で良さそうです。ただし、IBM i の場合、S922 は 1LPAR 4core までです。 ・「コア」は「0.5」core、「メモリ」は「4」GBとします。 ※今回のデモ環境構築としてのリソースはこれくらいあれば足りるかな・・と仮置きで決めました。 コアとメモリーはインスタンス作成後、柔軟に変更できます。 「ストレージ・ボリューム」の選択画面です。 ・「新規ストレージ・ボリューム」をクリックします。 AIXでは初期で20GBがrootvgに割り当てられており、ストレージを追加しなくてもインスタンスは作成できますが、後でソフトウェアを導入したいので、インスタンス作成段階で10GBを追加してみました。 ストレージ・ボリュームはインスタンス作成後でも追加できます。 ・「名前」に任意の名前「stg01」を入力します ・「サイズ」は「10GB」で、「数量」は「1」とします ・「作成して接続」をクリックします。 ・作成した「stg01」がリストアップされます。 「ネットワーク・インターフェース」の選択画面です。 ・「パブリック・ネットワーク」を「オン」にします。 既存のプライベート・ネットワークは持っていませんので、インターネット回線を利用したパブリック・ネットワークで検証を行います。 これでインスタンス作成前の全ての選択が完了しました。 ・「使用条件に同意する」に「✓」を入れ「インスタンスの作成」をクリックします。 ※このボタンをクリックすると課金が発生します。 さすがIBM！ストレージの料金が安いですね。 「インスタンスの作成」をクリックした後は自動で「リソース・リスト」の画面に戻ります。 暫く反応がなくてドキドキしますが、3~5分後にメッセージが出力され始めます。 インスタンスの「状況」が「ビルド」→「警告」→「アクティブ」に変わり、「アクティブ」になったらインスタンスの作成が完了です。 ・「名前」の「AIX72_test」の項目がリンクになっているのでクリックし、作成したインスタンスの「詳細」を確認します。 これで、AIXインスタンスの作成は完了です！ 続きは、 【やってみた】IBM Power Virtual Server のAIX環境にSWを導入してみた でご紹介しています。 ＜続きの内容＞ ③ AIXインスタンス 接続 ④ ストレージ・ボリュームの反映 ⑤ ソフトウェア導入 最後に ここまでの作業は（SE歴が遠い昔）の私にも楽勝でした。 インスタンスが数分で作成できるのは、ちょっとした感動です。 今回の検証は、IBM Partner Package (IBMサイト)で提供されている IBM Cloud クレジットを利用しました。 定められているクレジット内（料金枠内）で Power Virtual Server のみではなく、IBM Cloud の様々なサービスを自由に使うことができます。 自分のIBM ID で Partner Package を利用する際は、企業とIBM IDの紐づけが必要になります。 手順が分からない、という方はご相談ください。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp 参考情報 IBM Power Virtual Server (製品情報)
皆さま、こんにちは。てくさぽBLOG メンバーの 岡田です。 エヌアイシー・パートナーズでは2016年からCisco Unified Computing System（以下 UCS）の取り扱いを始めています。 UCSが発表されてから既に10年以上経っておりますが、再びUCSが注目を浴びています。今回は、これからUCSを検討しようとお考えの皆さんに向けて、その特徴やメリットをお伝えします。 1. Cisco UCSとは ずばり、Cisco社製のIA（Intel Architecture）サーバです。 Intel製CPUが搭載されているので、Windows Server/Linux/VMware ESXiなどの、Intel CPU用のサーバOSがUCS上でも稼働します。 では、なぜネットワーク機器のベンダーであるCiscoがIAサーバを出したのでしょうか。 仮想化が一般化した現在のデータセンターでは、サーバ、ネットワーク、ストレージ、アプリケーションといった各構成要素を個別に構築、デザイン、最適化するサイロ型になっています。その結果として、各コンポーネント個別の管理となり、管理者間の連携の煩雑さや環境変更時の検討項目・調整・検証期間工数の増大が大きな課題となっています。 これらの問題を解決するために、UCS は、仮想環境やクラウド環境で利用されることを念頭に置き、すべてのコンポーネントを全体最適化されたアーキテクチャの下に統合することで、複雑さをなくし、リソース管理を容易にし、最適な仮想環境を実現しています。つまり、サーバやネットワークを大きな1つのリソースとして一元管理することにより、管理・運用がしやすくなるということです。 （UCSの全体最適化されたアーキテクチャ） 2. 他社IAサーバとの違い では、UCSは他社IAサーバと比べて、どんなところが違うのでしょうか。UCSが他社IAサーバと異なるところは主に以下の３点になります。 ファブリックインターコネクト ユニファイドポートという1Gbまたは10Gbのイーサネットポート、またはファイバーチャネルポートのどちらにも設定できるスイッチポートを搭載したスイッチです。一般的なIAサーバでは、ネットワークスイッチとファイバーチャネルスイッチそれぞれに接続しますが、UCSサーバは基本的にこのファブリックインターコネクトとのみ接続します。 UCS Manager ファブリックインターコネクトに搭載された統合管理コンソールです。接続されたBladeサーバ、ラックサーバを一元管理します。 サービスプロファイル UCSでは、サーバのハードウェア各種設定情報をサービスプロファイルとして保持し、これを実際のハードウェアに関連付けることでサーバやネットワークの設定を行います。 Intersight Intersightはオンプレミスにある複数のCisco UCSやHCI製品のHyperFlexを統合的に管理するためのSaaSサービスです。地理的に離れた環境にある複数システムを一元管理できます。SaaSサービスなので管理サーバーを用意する必要がなく、管理者はどこからでも管理ダッシュボード画面にアクセスできます。 このような違いを持つUCSを選択すると、どのようなメリットがあるのでしょうか。 3. UCSのメリット シンプルな構成 UCSサーバはファブリックインターコネクトとのみ10Gbイーサネットケーブルで接続します。この10Gbイーサネットケーブルの中に、イーサネットとファイバーチャネルの両方のプロトコルが流れます。 これにより、ラック背面のケーブル本数が激減し、より適切なエアフローと低い消費電力を実現します。この結果として、データセンターのファシリティコスト、配線コスト、配線トラブルを削減できます。 管理ポイントの削減 UCSでは、サーバやBladeシャーシ毎に管理モジュールを持たず、ファブリックインターコネクト上にあるUCS Managerで一元管理されます。これにより、台数が増えても管理ポイントはUCS Manger１箇所のみのままですので、管理対象が増えません。これにより、個々の機器毎に管理する必要がなくなり、管理工数を削減できます。 シンプルな運用 サービスプロファイルを利用することで、構築時や障害発生における機器交換時において時間がかかっていたハードウェア設定作業を大幅に削減することが可能になります。他社IAサーバでは、サーバ導入時にさまざまな設定を個々に実施する必要がありますが、サービスプロファイルを利用するとハードウェアにプロファイルを割り当てるだけでハードウェア設定が完了します。また、機器が届く前にMAC アドレスなどの予約や、BIOS の設定を先にやっておくといったことも可能になります。 ラックマウントサーバの統合 ファブリックインターコネクト配下に接続することで、UCS Managerによる統合管理機能を、サーバ形状を問わずに一元管理可能になります。 このような特徴を持つUCSですが、エヌアイシー・パートナーズでは日本IBM社が取り扱う、IBM保守のUCSをお勧めしています。 4. IBM保守 UCSの特徴 IBM技術員によりオンサイト保守を実施します。 スペシャリストによりリモート問題判別支援をおこないます。 保守時間帯の選択が可能です。 UCSの運用を支援するオプション（交換したハードディスクのお渡しサービスと部品2時間配送サービス）を追加できます。 5. まとめ いかがでしたでしょうか。UCSはサーバメーカーとしては後発であることのメリットを活かして、これまでのIAサーバが抱えていた課題を解決できるソリューションを備えています。これにIBM保守を加えることで、ネットワーク機器からサーバまで保守をまとめてIBM社に一元化することができます。現在のデータセンター運用に課題を抱えたお客様にはぜひUCSをご検討ください。 また、エヌアイシー・パートナーズではUCSとIBMストレージ、ネットワークスイッチ等の複雑な組み合わせでの構成でも対応可能です。ご相談からお見積り依頼まで、遠慮無くお申し付けください。 最後に、弊社サイトのUCSページにてラインナップや支援内容などを記載していますので、こちらももぜひ御覧ください。 https://www.nicpartners.co.jp/products/72456/?from_category=category_all 【変更履歴】 2020/12 Intersight説明を追加。弊社サイトのUCSページへのリンクを修正。 この記事に関する、ご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp 商標帰属 ・すべての名称ならびに商標は、それぞれの企業の商標または登録商標です。
IBM の岡田です。 いよいよシリーズ物、最後のテーマまでやってきました。 ここまでの内容はいかがでしたでしょうか？もう少しで完結しますので、最後までお付き合いいただければと思います。 さて、今回のテーマは「データを守ることについて」ということで、様々な脅威からどうやってデータを守るか、という内容でお届けします。 データを脅かす脅威とは 一昔前までは、データの脅威といえば人為的オペミス、装置の故障・障害、災害などが挙げられてました。しかし、最近はこれに加えサイバー攻撃といったものも加わってきております。 今まではサイバー攻撃というと、ネットワークあるいはサーバーにて対処すべきもの、という考え方が主流だったかと思います。これらはサイバーセキュリティという範疇の対策であり、今までも多くの製品やサービスによって培われてきた技術です。 しかし、昨今のサイバー攻撃はマルウェアが主流となっており、特にランサムウェアと呼ばれる攻撃が世間的にも目立ち始めてます。企業のデータを強制的に暗号化し解除するための身代金を要求するというものです。 確か最近ニュースで、日本での被害のとんでもない状況を目にした覚えがあります。調査対象の半数以上の企業は攻撃を受けた経験を持ち、実際に身代金を払った会社も調査対象の約3分の１あったということ、また、本当に支払われた身代金も平均が億を優に超える金額だったことに筆者も驚きました。 ということで、今回はストレージ技術にできるデータの保全について、従来の物理的な脅威から守ること、今日のサイバー攻撃から守ることの2つに分けてお話していきます。 物理的な脅威からデータを守る 止まらないシステムを構築するために、IT の世界では様々な対策が体系化し今日に至ってます。 全ての ITインフラを成す要素を冗長化するといったものはごく当たり前で、IT技術者なら必ず取っている対策ですね。機器自体も各パーツが冗長化されいつでもホットスワップでパーツ交換できるような仕組みになっているのが現在の IT機器です。 このように、シングルポイントになり得る構成をできる限り排除することで物理的な機器の障害や故障からシステムを守る、というのが今時当たり前のシステム設計なのはご存知の通りです。 データについてはどうでしょう。 システム構成の一部としてデータの通り道も冗長化されているのが昨今の設計ですが、データを貯める場所、つまりストレージについては過去より多くの技術が使われてきております。 パーツとしての HDD 等に用いられる磁気ディスクの盤面に書き込む際のフォーマットについては、ECC（Error Check and Correction）と呼ばれる技術、すなわちデータをビット化けや傷・汚れなどによるディスク上の脱落から計算により正しいデータを導くテクノロジーが用いられております。 さらに上のレイヤーでは、HDD や SSD などデイバイスの故障に対応するために、RAID といった技術が使われていることも多くの IT技術者はご存知でしょう。 最近は大容量下での再構成の長時間化などを改善するため、各社独自の RAID技術を駆使していたり、イレージャーコーディングといった、今まではディスク盤面などミクロな世界で行われていたような ECC をベースとした考え方を、装置・筐体といったレベルまで広げた技術などが使われ始めています。 最近のストレージ装置はユーザーに開放している論理ボリュームに対して、そのコピーを複数個筐体内に取って世代管理することもありますし、筐体間レプリケーションで別の安全な場所にコピーを取るということもできます。 そして、昔からあるオーソドックスな方法としては、ある時点のデータを静的に固めて安全な媒体に書き出して取っておく、所謂、バックアップが一番一般的ではないでしょうか？ しかし、実はバックアップ技術も1990年代のような、ただテープ媒体などに静的データを単純にとれば良いという時代はとっくに終わっており、今やバックアップ先データ容量を極限まで抑える技術であったり、転送を効率的に行う技術であったり、いろいろな技術が併用されております。 少し簡単に紹介しましょう。以下にご紹介するのは IBM Spectrum Protect と呼ばれるバックアップソフトで使われている技術です。 1. 永久増分バックアップ 初回バックアップのみフルバックアップを取り、その後のバックアップは増分（差分）のみ。 こうすることでバックアップ先データに必要な容量を格段に節約することができますし、このデータを遠隔にレプリケーションする際もデータ量が少ないため、ネットワークに余計な負担をかけずに済みます。 図1. 永久増分バックアップ 2. 重複排除・圧縮技術 すでに枯れた技術で、ストレージ装置にも使われているものですが、特に重複排除については過去のバックアップデータとの重複もあるので、さらに効果が見込まれます。 また、VM などの仮想環境でも似たディスクイメージを扱うことで、重複排除率は格段に上がります。 図2. 重複排除 3. FASP技術 バックアップデータを DR 目的で遠隔に飛ばす際には、ネットワーク帯域を通常の TCP/IP より効率的に使用できる FASP（Fast Adaptive Secure Protocol）により、高速転送が可能となります。 図3. FASP転送 4. 今時のバックアップ先ストレージ バックアップのとり先といえば、昔はテープ、そしてディスクの時代があり、最近はまたテープが見直されてきています。 理由はもちろんビット単価であったり可搬性であったりが主ですが、後述するサイバー攻撃対策としても最近は注目されています。 最新技術活用という点では、クラウドのオブジェクトストレージにバックアップするというのも出てきています。その基本的な3形態を示したのが次の図です。 図4. バックアップ3形態 悪意のあるサイバー攻撃からデータを守る ここまでは、レガシーな考え方、つまり物理的な脅威への対策としての最新のバックアップ技術です。 ところが昨今はこう言った脅威のみならず、意図的なデータ破壊や改竄への脅威、つまりサイバー攻撃への対策というものが必要になってきています。 そもそも色々な技術の蓄積で現在のサイバーセキュリティ成り立っていますが、攻撃者とのいたちごっこであることは否めません。したがって、突破された際の対策というものも必要になります。 最近のデータによると、実際にハッカーあるいはマルウェア等に侵入されたことが発覚するまでの日数は数百日とも言われており、わかった時にはすでに多くのデータの破壊・改竄・漏洩がなされた後、ということになりかねません。 このうち、破壊・改竄はデータが失われる訳で、データを使った企業活動ができなくなるという致命的な結果になり得ます。ゆえに、破壊・改竄（ランサムウェアによる強制的暗号化も含む）への対策が必要となるわけです。 図5. サイバー攻撃の際、データが役に立たなくなる 多くの場合、ネットワーク越しにサイバー攻撃が行われます。つまり、バックアップがあるから大丈夫と思っていても同じネットワーク内にあれば同様に犯された使えないバックアップデータとなる可能性が出てきます。 そこで、覚えていただきたいキーワードがあります「エアギャップ」と「イミュータブル」。 サイバーレジリエンシーの基本的な考え方です。 図6. エアギャップ・イミュータブル 前者は、ネットワーク的なつながりのない場所・物・仕組みを指し、後者は、改竄できない場所・物・仕組みをさしています。 つまり、バックアップなどの最後の砦となりうるデータは、こういったエアギャップ対応、あるいはイミュータブル対応のなされたメディア・機器・場所・仕組みなどに置くことで、初めてサイバー攻撃からデータを守るということができるわけです。 もちろん RPO がゼロになるわけではないので失うものも若干ありますが、億単位の身代金を支払うことからは救われます。 RPO をゼロに近くするためには当然、検知能力を上げる他ありません。 サイバーセキュリティで 100％検知できればこのような不幸は起こりませんが、万一気づかずネットワーク内に攻撃が入ってしまった場合も、データ側の仕組みで検知することもできるかもしれません。以下に二つの検知技術を紹介します。 図7. IBM Spectrum Protect の検知機能 こちらは、定常状態と大きなデータの変化のあった状態との差からサイバー攻撃の可能性の有無をチェックする機構です。 データが暗号化されたり破壊されたりすると、直前のバックアップデータとは大きく異なるデータとなるため、当然の事ながら重複排除率は極端に低くなります。さらに、圧縮率やファイルの増加数など、定常時とは異なる変化が現れるでしょう。 そういった変化を検知することで、データに何か大きな変化があったこと、すなわち破壊・改竄の可能性をいち早く検知することができるわけです。 次に、例えば IBM の Spectrum Scale には File Audit Logging という機能があります。 これをサイバーセキュリティの仕組みで検知系に繋げてあげれば、いち早くおかしなデータから本番データを守ることができるわけです。 図8. IBM Spectrum ScaleとQradar によるサイバー攻撃の検知 サーバー攻撃と対策のいたちごっこは、これからも続いていくでしょう。 しかし、アンチウィルス系の対策のようにウィルス自体のシグネーチャーやパターンに頼った対策は、必ず後手となります。そういう意味で、定常状態との変化で検知する方法は非常に有効な手段かと思われます。 ぜひ有効な対策を打って、備えを万全にしていきましょう！ 約半年にわたってブログを書かせていただきましたが、少しでも IT を担う皆様にお役に立つことができると幸いです。 ありがとうございました！ この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 参考ページ IBMストレージ製品 (製品情報) 全包囲網。。。最新 IBMストレージ 概要 (ブログ) OpenShiftに代表されるコンテナ環境へのIBMストレージの対応 (ブログ) ハイブリッド/マルチクラウド時代だからこそIBMのストレージ (ブログ) AI導入はどこまで現実的？ 5大ハードルとその解決策を解説 (ホワイトペーパー) 普及が進む、機械学習による異常検知。導入の課題はここまで解決している (コラム) データ・ファーストのハイブリッドクラウド基盤を実現するIBMストレージ (IBMサイト) ハイブリッドクラウドにおけるデータ連携の鍵を握るもの (IBMサイト) .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
こんにちは。てくさぽBLOGメンバーの佐藤です。 最近でも、10GbpsEtherを含めたサーバの構成依頼を多くいただきます。 種類がいくつかありますので、どの10GEtherにしましょうか?と確認すると 種類が多すぎてどれにしていいかわからない、どうお客様にヒヤリングしていいかわからない といったお困りの声が多いため 今回は、何を選定していいか迷ってしまいがちな「10GbpsEther」について改めて解説いたします。 10GbpsEtherとは？ 読んで字の通りですが従来のGbitEtherの後継で10倍の転送速度を持つEtherとなります。 10GbpsEtherの難点は複数の種類があるところです。 代表的なものを以下にあげます。 なお、これ以外にもありますが現在あまり販売していないもの、WAN回線用の長距離通信の規格については除いています。 ･10GBASE-T ･10GBASE-SR ･10GBASE-LR ･10GBASE-SFP+ それぞれについての技術的な解説等は多数のサイトにお任せするとして 本ブログでは、 何を選択すればいいか?に焦点を絞って解説致します。 10GbpsEtherを選定する際は基本的には以下の2つの要素から決めます。 1.汎用性 2.配線距離 1.汎用性 2016年8月現在、サーバに搭載する10GbpsEther汎用性ランキング＊は以下の通りです。 ＊個人的な感覚を含みます。 ランキング 名称 成長率 1位 10GBASE-SFP+ → 2位 10GBASE-T ↑ 3位 10GBASE-SR → 4位 10GBASE-LR → 1位は10GBASE-SFP+としています。 今買うのであればもっとも普及しており、汎用性が高い規格となります。 スイッチの種類も豊富です。 ただし、今後は10GBASE-Tの動向次第といったところです。 2位の10GBASE-Tは、期待を背負って最後に登場した規格となりますが 様々な理由から穏やかに成長しており、価格的にも今のところは10GBASE-SFP+と同じくらいです。 しかしながら、RJ-45コネクタおよびメタルケーブル接続という潜在的なコストメリットは最も高いため、今後普及がさらに進めば価格が下がることが期待されます。 3位以下は次にあげる配線長の理由が無い限り特に大きなメリットが感じられません。 2.配線距離 各規格の最大配線長は以下の通りです。 配線長 名称 種類 ~10m 10GBASE-SFP+(Cu Twinnax) メタル ~100m 10GBASE-T メタル ~300m 10GBASE-SR 光(MMF) ~10km 10GBASE-LR 光(SMF) SFP+(Cu Twinnax)はダイレクトアタッチケーブルと呼ばれるものです。 最大10m以下となりますので、実質ラック内配線専用となります。 10GBASE-Tの最大長は最も高品質なCat6a/Cat7ケーブルを使った場合で100mまで、Cat6/Cat6eですと55mまでとなります。 そのため、データセンターなどの広いフロア内の配線や、上下階配線ではやや物足りない長さとなります。 10GBASE-SRはOM3という高品質光ケーブルを使用すると300mまで伸ばすことができます。 300mあれば、フロア内配線で困る事は無いでしょう。 10GBASE-LRは最大長10kmと敷地内の棟をまたぐような特別長い配線をする場合に必要になります。 基本的にスイッチ間接続が主用途となります。 10GBASE-SFP+ ここで、SPF+について補足します。 上記の通り、10mまでしか配線出来ないのであればSPF+は汎用性高くないではないか？ と疑問に思われる事でしょう。 しかし、SFP+は、モジュールを選択することによって10GBASE-SFP+(Cu Twinnax)と10GBASE-SR両方に対応可能です。 たとえば、ラック内配線では10GBASE-SFP+(Cu Twinnax)で安価に、ラック外との接続はSRトランシーバーを使用し光ファイバで接続といった具合に、メタルケーブルの経済性と光ケーブルの長距離、高品質を両立させることができます。 設置環境の情報が不明なケースが多いため、私はもっとも汎用性が高いSFP+を選択することが多いです。 10GBASE-SFP+(Cu Twinnax)_ダイレクトアタッチケーブルの例 10GBASE-SFP+ SRトランシーバモジュールの例 まとめ さまざまな規格が存在する10GbpsEtherの世界ですが、今から購入するのであれば10GBASE-SFP+か10GBASE-Tのどちらかとなります。 今のところ迷ったり、指定がない場合、汎用性と配線距離を踏まえてSFP+を選択します。 10GBASE-Tについては、現状ではSFP+と比較して ・RJ-45ではあるが、ケーブルを引き直す必要が有り、配線を流用できない ・最大ケーブル長がSFP+と比較して短い ・消費電力が高め(改善されつつある) ・高レイテンシ となり、積極的に選ぶか?といわれると意見の分かれるところになります。 敷設のしやすさ、ケーブルの取り回しのしやすさ1GbpsEtherとの接続性といった点を 評価するのであれば 10GBASE-Tとなります。 普及が進み、スイッチ含め、価格がもう一段下がれば基本は10GBASE-Tで構成となるかと思います。 ※SFP+ダイレクトアタッチケーブルを使用する場合の注意点(2018/11/2追記)※ SFP+のダイレクトアタッチケーブルですが、ネットワークスイッチ側で制限がかけられているケースがあるようです。 具体例ですとCISCOのCatalystシリーズと接続する場合はCISCO以外のメーカーのケーブルを接続するとリンクアップしないようです。 Catalystの場合、回避策がありますので知りたい方は”#no errdisable detect cause gbic-invalid”や”#service unsupported-transceiver”で検索ください。 ダイレクトアタッチケーブルの場合、サーバーとネットワークスイッチのメーカーが違う場合は相互にサポートするケーブルはありませんのでサポートを気にされる場合は、SRトランシーバーでの接続をお勧めいたします。 以下は、ダイレクトアタッチケーブルの適合性についての資料となりますがこちらのリンク先の資料については、各メーカーのサポート状況をまとめたものではなく、あくまで互換SFP+モジュールを販売しているPanduit社の調査結果に基づくデータとなります。 こちらの情報で使用可能となっていても、メーカーのサポートは受けられない、もしくは動かないケースもあり得ます。 あくまで自己責任の範囲でご参照ください。 http://www.panduit.com/heiler/TechnicalReferences/D-COTR104--WW-JPN-Rev2-SFPCprCblAsmbl.pdf http://www.panduit.com/heiler/TechnicalReferences/D-COTR104--WW-ENG-Rev5-SFPCprCblAsmbl.pdf 25GbpsEtehrの記事も追加しております。 ↓↓↓↓↓↓↓↓↓↓↓↓↓↓ いまさら聞けない25GbpsEther この記事に関する、ご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp
※IBM Cloud Pak for Applications の新規販売は終了いたしました。今後のアプリケーションランタイムソリューションは、2021年1月15日に発表された「WebSphere Hybrid Edition」となります。 ＊ ＊ ＊ ＊ ＊ ＊ こんにちは。てくさぽBLOGメンバーの岡田です。 第1回、第2回に続き、今回は AWS上に構築した Openshift環境に Cloud Pak for Applications（以下 CP4A）をインストールします。 目次 事前準備 インストール実行 ２－１．Entitlement Keyの入手 ２－２．インストール構成ファイルをインストーライメージから取り出す ２－３．インストーラの実行 ２－４．インストール後の確認 つまづいたポイント 最後に お問い合わせ １．事前準備 環境 Openshift 4.3.22（AWS上にCloudFormationを用いて構築）※構築したOpenshift環境にocコマンドでログインできることを確認 CP4A 4.0.1 用意するもの IBMid Dockerコマンド 17.05以上の実行環境 ２．インストール実行 ２－１．Entitlement Keyの入手 "MyIBM Container Software Library"にアクセスし、Entitlement Keyをコピー※アクセスすると IBMid でのログインが求められるので ID・パスワードを入力してログインし、以下の画面に遷移したら「キーのコピー」をクリックします。 ２－２．インストール構成ファイルをインストーライメージから取り出す 以下のコマンドを、docker をインストールした端末から実行 # export ENTITLED_REGISTRY=cp.icr.io # export ENTITLED_REGISTRY_USER=cp # export ENTITLED_REGISTRY_KEY=<apikey> ※apikeyは2-1.でコピーしたライセンス・キーです。 「entitled registry」にログイン # docker login "$ENTITLED_REGISTRY" -u "$ENTITLED_REGISTRY_USER" -p "$ENTITLED_REGISTRY_KEY" WARNING! Using --password via the CLI is insecure. Use --password-stdin. WARNING! Your password will be stored unencrypted in /root/.docker/config.json. Configure a credential helper to remove this warning. Seehttps://docs.docker.com/engine/reference/commandline/login/#credentials-store Login Succeeded dataディレクトリを作成し、そこに「configurationファイル」を展開 # mkdir data # docker run -v $PWD/data:/data:z -u 0 -e LICENSE=accept "$ENTIITLED_REGISTRY/cp/icpa/icpa-installer:4.0.1" cp -r "data/*" /data Unable to find image 'cp.icr.io/cp/icpa/icpa-installer:4.0.1' locally 4.0.1: Pulling from cp/icpa/icpa-installer 964d57e311cc: Pulling fs layer 6d1814359c74: Pulling fs layer 77181019ed4d: Pulling fs layer 60aa381192cc: Pulling fs layer （途中省略） 2.602kB/2.602kB7d09be603f64: Extracting 2.602kB/2.602kB7d09be603f64: Pull complete df8e82fdbe08: Extracting 32.77kB/925.6kBdf8e82fdbe08: Extracting 925.6kB/925.6kBdf8e82fdbe08: Pull complete b0cda391a0db: Extracting 32.77kB/973kBb0cda391a0db: Extracting 973kB/973kBb0cda391a0db: Extracting 973kB/973kBb0cda391a0db: Pull complete Digest: sha256:a1c6c478dfb4d2039df385f8a75ecf3e6d358e35f8d662afc506b6bbc5d308af Status: Downloaded newer image for cp.icr.io/cp/icpa/icpa-installer:4.0.1 # dataディレクトリに4つのyamlファイルが作成されたことを確認※"config.yaml" "kabanero.yaml" "servicemesh.yaml" "transadv.yaml"が作成されます。 # ls -la data 合計 20 drwxr-xr-x. 2 root root 91 4月 21 10:44 . dr-xr-xr-x. 21 root root 4096 4月 21 10:40 .. -rw-r--r--. 1 root root 704 4月 21 10:44 config.yaml -rw-r--r--. 1 root root 539 4月 21 10:44 kabanero.yaml -rw-r--r--. 1 root root 1299 4月 21 10:44 servicemesh.yaml -rw-r--r--. 1 root root 3792 4月 21 10:44 transadv.yaml ２－３．インストーラの実行 Openshift環境へログイン # oc login https://api.nicptestcluster.example.com:66443 -u kubeadmin -p〈kubeadminのパスワード〉 Login successful. You have access to 51 projects, the list has been suppressed. You can list all projects with 'oc projects' Using project "default". チェックコマンドの実行※最後に "Check successful" と表示されることを確認します。 # docker run -v ~/.kube:/root/.kube:z -u 0 -t -v $PWD/data:/installer/data:z -e LICENSE=accept -e ENTITLED_REGISTRY -e ENTITLED_REGISTRY_USER -e ENTITLED_REGISTRY_KEY "$ENTITLED_REGISTRY/cp/icpa/icpa-installer:4.0.1" check Starting Check ***************************************************************** Login To Cluster... ok stdout: Using environment variables to log-in to cluster. Login successful. You have access to 57 projects, the list has been suppressed. You can list all projects with 'oc projects' Using project "openshift-marketplace". Get Cluster Server Address... ok （途中省略） Check Existing OpenShift Serverless Subscription... skipped Check Existing OpenShift Pipelines Subscription... skipped Check Existing Appsody Subscription... skipped Check successful *************************************************************** インストールの実行※チェックコマンドで問題がなければ実行します。（チェックコマンドとは、最後のパラメータが "check" か "install" かの違いです）※最後に "Installation complete" と表示されることを確認します。 # docker run -v ~/.kube:/root/.kube:z -u 0 -t -v $PWD/data:/installer/data:z -e LICENSE=accept -e ENTITLED_REGISTRY -e ENTITLED_REGISTRY_USER -e ENTITLED_REGISTRY_KEY "$ENTITLED_REGISTRY/cp/icpa/icpa-installer:4.0.1" install Starting Install *************************************************************** Login To Cluster... ok stdout: Using environment variables to log-in to cluster. Login successful. You have access to 57 projects, the list has been suppressed. You can list all projects with 'oc projects' Using project "openshift-marketplace". Get Cluster Server Address... ok （途中省略） Mark Installation Complete... done Install successful ************************************************************* Installation complete. Please see https://ibm-cp-applications.apps.nicptestcluster.example.com to get started and learn more about IBM Cloud Pak for Applications. The Tekton Dashboard is available at: https://tekton-dashboard-tekton-pipelines.apps.nicptestcluster.example.com. The IBM Transformation Advisor UI is available at: https://ta-apps.apps.nicptestcluster.example.com. The IBM Application Navigator UI is available at: https://kappnav-ui-service-kappnav.apps.nicptestcluster.example.com. ２－４．インストール後の確認 インストール画面に表示されたCloud Pak ConsoleのURLにアクセス ※Cloud Pak Console には OpenShift Webコンソールからもアクセスできます。画面右上の四角形のアイコンをクリックすると "Cloud Pak for Applications - Cloud Pak Console" が確認できます。 以上で CP4A のインストールは完了です！ ３．つまづいたポイント インストールがエラーで完了しない… 作業当初は、OpenShift4.2.23 上にてインストールを開始しました。 「チェックコマンドの実行」までは正常に完了しましたが、次の「インストールの実行」でエラーとなりました。 # docker run -v ~/.kube:/root/.kube:z -u 0 -t -v $PWD/data:/installer/data:z -e LICENSE=accept -e ENTITLED_REGISTRY -e ENTITLED_REGISTRY_USER -e ENTITLED_REGISTRY_KEY "$ENTITLED_REGISTRY/cp/icpa/icpa-installer:4.0.1" check Starting Check ***************************************************************** Login To Cluster... ok （途中省略） Retrying... (39 of 41) Retrying... (40 of 41) failed msg: non-zero return code stdout: The kappnav-ui pods are not created. Check logs for details. Install failed ***************************************************************** このログをみる限り kappnav-uiポッドが立ち上がってこない状況で止まっていますので、続いて pod のログを確認しました。 # oc describe kappnav.kappnav.io/instance -n kappnav Name: instance Namespace: kappnav Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"kappnav.io/v1alpha1","kind":"KAppNav","metadata":{"annotations":{},"name":"instance","namespace":"kappnav"},"spec":{"appNav... API Version: kappnav.io/v1alpha1 Kind: KAppNav （途中省略） Status: Conditions: Last Transition Time: 2020-05-12T07:50:44Z Status: True Type: Initialized Last Transition Time: 2020-05-12T07:50:48Z Message: failed to install release: chart requires kubeVersion: >=1.11.0 which is incompatible with Kubernetes v1.14.6-152-g117ba1f Reason: InstallError Status: True Type: ReleaseFailed Events: <none> # 続いて Openshiftクラスターの Kubernetesバージョンを確認すると、"v1.14.6+8fc50dea9" でした。 # oc get nodes NAME STATUS ROLES AGE VERSION ip-10-0-48-228.ap-northeast-1.compute.internal Ready worker 51d v1.14.6+8fc50dea9 ip-10-0-49-10.ap-northeast-1.compute.internal Ready worker 51d v1.14.6+8fc50dea9 ip-10-0-50-165.ap-northeast-1.compute.internal Ready master 52d v1.14.6+8fc50dea9 ip-10-0-58-201.ap-northeast-1.compute.internal Ready master 52d v1.14.6+8fc50dea9 ip-10-0-59-142.ap-northeast-1.compute.internal Ready master 52d v1.14.6+8fc50dea9 その後、いろいろと調査をしたのですが原因が特定できなかったため、4.0.1 がサポートしている Openshift の最新バージョン 4.3.22 にアップデートをして再度 CP4A のインストールを実施したところ、無事完了しました。 4.3.22 にバージョンアップ後の oc get nodes 結果です。4.2.23 のときについていた "+xxx" という文字列は無くなり "v1.16.2" となっています。 $ oc get node NAME STATUS ROLES AGE VERSION ip-10-0-48-228.ap-northeast-1.compute.internal Ready worker 213d v1.16.2 ip-10-0-49-10.ap-northeast-1.compute.internal Ready worker 213d v1.16.2 ip-10-0-50-165.ap-northeast-1.compute.internal Ready master 213d v1.16.2 ip-10-0-58-201.ap-northeast-1.compute.internal Ready master 213d v1.16.2 ip-10-0-59-142.ap-northeast-1.compute.internal Ready master 213d v1.16.2 原因を特定できなかったのは残念でしたが、つまづいたら一旦環境を最新にしてエラーが再現するかを確認する、という問題解決の基本を改めて実感しました。 最後に いかがでしたでしょうか。一部の dockerコマンドが長くて難しく感じましたが、手順そのものは前回ブログでの Openshift構築と比べると工程数は非常に少ないので、それほど CP4A のインストールは難しくないと、実際に検証してみて感じました。 皆様の CP4A構築にこの記事が参考になれば幸いです。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社技術支援本部E-Mail：nicp_support@NIandC.co.jp .highlighter { background: linear-gradient(transparent 50%, #ffff52 90% 90%, transparent 90%); } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_A{ height:30px; } .btn_A a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; } .smaller { font-size: smaller; }
IBM の岡田です。 「最新のデータライフサイクル管理とは？（前編）」では "データの価値" や "IBM Spectrum Scale" についてのお話をしました。 後編は "IBM Cloud Object Storage" とは何か、といったことから、続きのお話をしていきましょう。 IBM Cloud Object Storageとは 先にデータの価値の話をしました。今度は昨今のデータの在り方のお話から入ります。 ここ10年ほどの間に、データの中心はトランザクション系の構造化データからビデオコンテンツや写真や IoT のセンサーデータなどの非構造化データにシフトしています。 近年その伸びも2年ごとに90％レベルの伸びを示しており、現在世の中のデータはすでに数十ゼタバイト程とも言われています。 つまり、これからのストレージはその容量の拡大についていく必要があり、そのような大容量下でデータ保全していかなければならないということです。 このような膨大な非構造化データの保管に向いているのが、オブジェクトストレージと言われるものです。（ブロック・ファイル・オブジェクトの違いはGoogle検索してみると色々解説がありますので、そちらをご参照ください） オブジェクトストレージには以下の特徴があります。 階層を持たない API による I/O 複数ノードによる分散保管 IBM Cloud Object Storage（以降 ICOS と呼ぶ）はこの複数ノードによる分散保管を地域レベルまで広げ、複数サイトでデータを持ち合う（ただしミラーではない）ことで地域災害などサイトレベルでのダウンにも対応できる保全性を実現します。 これにはイレージャーコーディングという RAID とは別のデータ保全の仕組みが使われてます。 RAID の問題点は、扱う容量が大きくなればなるほど障害後の再構成の時間がかかるようになるということ。この再構成時に新たな障害が発生するとデータロストに繋がります。 ICOS で使われる Information Dispersal Algorithm（以降 IDA と呼ぶ）というイレージャーコーディングをベースにした技術は、複数ディスク、複数ノードの障害を許容する、さらに言えば、ハードウェアは壊れることが当然、という思想の元に出てきたデータ保全方法のため、ある閾値に達するまではハードウェアの障害に影響されず、データの読み書き、運用が正常に行われます。 閾値で許容される障害ノード台数がサイトのノード数以上であればサイト障害にも耐えうる、ということです。 図6. IBM Cloud Object Storageの基本的なアーキテクチャー IBM Cloud 上でもこの ICOS を使った月額課金のオブジェクトストレージを提供していますが、アジア圏の場合、東京・ソウル・香港の3箇所に分散して ICOS を運用しております。 図7. IBM Cloud のオブジェクトストレージ（ICOS） このような3箇所ないしそれ以上の拠点に暗号化したデータを分散しておくことで、セキュアで信頼性の高いデータ保管が可能となり、現実に ICOS に保管されたデータの信頼性は最大 15ナイン（99.9999999999999%）とも言われています。 安い容量単価でデータの最後の砦としての信頼性を確保できるストレージとして、ICOS はテープと違った面で適していると言えます。 また ICOS は API でやりとりするという点でも、昨今の Cloud Native なアプリケーションとも相性が良く、AI や Analytics系でのデータ提供にも非常に適しています。 よって、非構造化データのような保管がメインで利活用の可能性が高いデータに最適な選択と言えるのが、IBM Cloud Object Storage です。 ICOS にはデータのライフサイクルを管理する上で重要な機能があります。 WORM という言葉をご存知でしょうか？ 元々は US で決められた法律に準拠したデータ保管のメディア方式の一つです。Write Once Read Many の略で、要は上書きが出来ず、改竄不能なメディアとして出来たものです。 ICOS にもこの WORM の機能があります。 WORM として設定されたエリア（一般的にはバケットにあたる。IBM では Vault と呼んでいる）にひとたびデータを書き込むと、そのデータは消去もできなければ改竄もできなくなります。データ保管の期間を設定することができるので、データライフが終わった時にタイムリーにデータを削除することも可能となります。 例えば、法律や規定等で保管年数を決められている契約書などの書類や、証拠物件として扱われる写真や帳簿類など、普段はアクセスすることもないが無くしてはいけない重要なデータのライフ管理には有効な手段となります。 また、最近はランサムウェアなどのデータ改竄（暗号化）に耐えうるバックアップデータエリアとしても注目されています。 IBM Spectrum Discover ここまでに示した通り、データはますます伸び率が高くなってきています。日ごとに増えるデータを扱う上でネックになるのが、データの特定等、保管データを後から扱うときの仕組みです。 最近のトレンドとしては、ファイルに関連づけられたメタデータや、ユーザーが自由に付加できるタグを活用しデータをカテゴライズしたり検索したり、といった作業が多くなっています。 IBM Spectrum Discover は、こういったメタデータ、タグデータをマネージするためのソフトウェアです。 明確には SDS というわけではなく、むしろデータマネージメントの意味合いが強いソフトウェアです。Discover の強みは、API を介して AI などにデータを食わせることができる、という点にあります。 例えば、画像データであれば画像解析の機能を持った AI（IBM では Watson Visual Recognition がこれに当たる）で画像に付随する情報を抽出し、これをタグデータとして付加する、といった作業を半自動的に行えることです。これにより、膨大なデータのカタログ化や一部のデータの抽出、あるいは不要であったりおかしなデータが紛れ込んでいないかなど、ガバナンスに対応することが可能です。 こうしたデータの利活用の方法も、大きな意味でデータのライフサイクルを支える新しい手法と考えられ、データマネージメントに寄与することができるわけです。 図8. IBM Spectrum Discover のデータマネージメントのイメージ 次回はデータを守ることについてお届けします。最後までお読みいただきありがとうございました。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 参考情報 IBMストレージ製品 (製品情報) 全包囲網。。。最新 IBMストレージ 概要 (ブログ) OpenShiftに代表されるコンテナ環境へのIBMストレージの対応 (ブログ) ハイブリッド/マルチクラウド時代だからこそIBMのストレージ (ブログ) AI導入はどこまで現実的？ 5大ハードルとその解決策を解説 (ホワイトペーパー) 普及が進む、機械学習による異常検知。導入の課題はここまで解決している (コラム) データ・ファーストのハイブリッドクラウド基盤を実現するIBMストレージ (IBMサイト) ハイブリッドクラウドにおけるデータ連携の鍵を握るもの (IBMサイト) .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
IBM の岡田です。 少し間が空きましたが、前回のハイブリッド/マルチクラウド時代だからこそIBMのストレージ は盛り沢山で機能豊富なブロックストレージを中心にクラウド連携のお話をさせていただきまいしたので、少々お腹いっぱいだったかもしれませんね。 今回はデータのライフサイクルを考えていくことで「ファイルストレージ」「オブジェクトストレージ」を前編/後編の2回でお話しさせていただきます。 データの価値 少々古いデータになりますが、以下は時間とともにデータの価値がどう変化するか、ということを示したグラフです。 「Development Code」のように多少の例外はありますが、多くは作られた直後のデータ価値が高く、時間とともにその価値は失われていくという傾向があります。 例外と言いましたが「Development Code」については以下ように解釈できます。 初期は完成に至ってないためコード価値は低く、実際に完成品となって初めてその価値が高くなる。そして製品のライフとともにコード価値が失われていくという意味において、コードの完成時をタイムゼロとみれば、他のデータとも同じ価値の変化を示すと考えられなくもないです。 これをもう少し概念的に捉えたものが次の図です。 図2. データの時間的価値変化のモデル 図に書かれたように、これらのデータにはその時の価値にふさわしい保管場所というものがあります。おそらくみなさんも切羽詰まった時、例えるならば PC のハードディスクがいっぱいになってしまった時など、慌てて古いファイル類を安価な記憶媒である DVD、BD、USB接続の外部記憶装置などに退避したり、使わないファイルを消去したりするのではないでしょうか？ 企業で取り扱う大量のデータでは、使わなくなったデータの保管にマッチした記憶デバイスへの移動をタイムリーに実施しないと、無意味に高価な保存スペースを浪費し、多くの無駄が発生します。 このようなことが無いよう、適切にデータのライフに合わせて保管場所を管理する必要があります。以前は、図3左側のように人手でこのような管理を行っていました。これでは手間がかかるだけでなく、ミスが生じてデータを消してしまったり、保管場所がわからなくなってしまうなど多くの不具合が生じる原因にもなりかねません。 このような手間をなくし、自動的に階層管理ができるのが、IBM Spectrum Scale です。 図3. データの階層化管理・今昔 IBM Spectrum Scaleとは IBM Spectrum Scale は、IBM が1990年代に開発した GPFS（General Parallel File System）と呼ばれる科学計算向けの高速ファイルシステムをベースに長年かけて熟成させたソフトウェア・デファインド・ストレージ製品です。 当初は AIX用に使われており、複数サーバーから同一ファイルへの同時アクセス可能とした当時としては先進的なファイルシステムで、特にグリッド系の処理に役立つものでした。 これをベースに様々な機能が付け加えられ、今日ではサーバーからアクセスしやすい NFS や SMB などの標準的なプロトコルに加え、HDFS にも対応した多目的使用に耐えうるものになっています。 この IBM Spectrum Scale には、図4に示す通り多くのハイパフォーマンス・ストレージに根ざした技術があり、また名前が示す通りスケールアウトすることで、より高速、より大容量を扱うことができるようなソリューションです。 現在では多くのスーパーコンピュータやハイパフォーマンスコンピューティングの分野で活用されています。 図4. IBM Spectrum Scale 全容 このように多くの機能がある中、当ブログではあえて自動階層化という機能に焦点を当ててお話をします。 Spectrum Scale は管理下に種類の異なる媒体を複数持つことができます。 この機能の例として、図5のように高価で高速な Flash系のストレージ、速度より容量重視の HDD、そしてテープ装置などで構成されたファイルシステムを見ていきましょう。 図5. IBM Spectrum Scale の自動階層化機能 これらの自動化にはどのように階層管理するかのルールが必要となります。配置ポリシー、移行ポリシーというのがそれにあたります。 配置ポリシーは、ファイルを書き込む際に何を基準にどの媒体・どの位置に書き込むかなどのルールを決めたものです。移行ポリシーは、すでに保管されているファイルがどのような条件で移動し、その際どの媒体・どの位置に移動させるかを決めるものです。 例えば、図5では、初期保管時にはフラッシュに書き込まれます。 次に保管期間が1ヶ月を過ぎると自動的に HDD に移動されます。この時ユーザーから見たファイルの位置は変わっておらず、書き込んだ時のフォルダーにそのまま存在して見えます。 さらに3ヶ月が過ぎるとフォルダーにスタブと呼ばれるリンクポインターのみを残し、ファイル本体はテープに移行されれます。ひとたびこのスタブにアクセスが生じると、ファイルはテープから書き戻され、また3ヶ月後にはスタブのみ残して元に戻ります。 というような、ファイルの価値にふさわしい媒体への移動を自動的に行うことで高価なデバイスの容量を減らすことができ、最終的にテープなどの安価なデバイスで管理することが可能となります。これにより、旬なデータの I/O パフォーマンスを損なうことなくストレージ全体のコストを減らすことにもつながります。 自動階層化の最終層には、テープの他にも、パブリッククラウド上のオブジェクトストレージなども有効です。こうすることで手元の余計な資産を減らすことにも繋がります。もちろんオンプレミスのオブジェクトストレージでも安価な容量単価を実現することができます。 「最新のデータライフサイクル管理とは（後編）」にて、そのオブジェクトストレージの IBM製品、IBM Cloud Object Storage のお話をしましょう。 最後までお読みいただきありがとうございました。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 参考情報 IBMストレージ製品 (製品情報) 全包囲網。。。最新 IBMストレージ 概要 (ブログ) OpenShiftに代表されるコンテナ環境へのIBMストレージの対応 (ブログ) ハイブリッド/マルチクラウド時代だからこそIBMのストレージ (ブログ) AI導入はどこまで現実的？ 5大ハードルとその解決策を解説 (ホワイトペーパー) 普及が進む、機械学習による異常検知。導入の課題はここまで解決している (コラム) データ・ファーストのハイブリッドクラウド基盤を実現するIBMストレージ (IBMサイト) ハイブリッドクラウドにおけるデータ連携の鍵を握るもの (IBMサイト) .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
