Find Communities by: Category | Product

『なんだか緊張するなあ。。200人の聴衆を前にプレゼンした時よりも緊張してますよ』

今回突撃したのは心なしかいつもの柔らかい笑顔もちょっと強張り気味?なXtremIOエキスパート、M-Itchy さん。

リリースされたX2-TとXtremIO 6.1 を引っ提げて東奔西走する中その熱い思いを聞いてみました。

 

MTEXIO4.JPG.jpg機は熟した・・・

ayas:では早速、新しいX2-TとXtremIO 6.1について教えてください。

M-Itchy:まずX2-Tリリースによる新しいエントリーモデルの追加。これによって今までXtremIOを視野に入れていなかったミッドレンジ系のお客様にもその良さを知ってもらえるようになりました。そしてソフトウェア面ではXtremIO 6.1でのReplication機能の追加。XtremIOネイティブのレプリケーション機能だからこそなしえる、これまでにない高効率な災害対策を実現します。

どちらもXtremIOへの間口を広げた!という点が今回の大きな目玉です。技術的な詳しい話はこちらにあるので是非!(オールフラッシュを前提に開発された「XtremIO」にエントリーモデルが登場 -その特徴とは?

もう一つ、今回は今までのXtremIO開発での新しい局面を迎えた第一歩、でもあるんです。

ayas:というと?

M-Itchy:実は3年前のバージョン4リリース以降、今回が初めての『機能追加』リリースなんです。普通ストレージはリリースのたびに新機能を追加することでその価値を付加します。でもXtremIOはそうして来なかった。XtremIOが目指したのは『システムの安定性』。だから余計な機能は追加しない。機能追加すると往々にして安定性の喪失や、性能劣化が発生する可能性が高くなりますから。しかし今回のXtremIO 6.1 で新機能追加が実現したのは、これまでの『XtremIO美学』を継承しつつも昨年リリースしたX2でのハードウェア、ソフトウェア面のスペックアップが機能追加を可能にしたからなのです。まさに『機が熟した』わけです。

MTEXIO7.JPG.jpg

無意識の不可能を可能へ パラダイムシフト

ayas:『XtremIO美学』をもう少し詳しく聞かせてください。

M-Itchy:世の中に多数あるAll Flashストレージの大半はHDD時代からのストレージをFlashカスタマイズしたもの、つまり、HDDをベースとしたアーキテクチャーなんですよね。一方、XtremIOFlashの登場以降に開発されたストレージなんです。つまり、高速な処理能力という側面だけでなく、時間経過とともに性能劣化が起きるなどの特性を全て考慮したストレージを一から創ることができたのです。こだわったのはFlash Diskの機能性を最大限に引き出し、常に一貫した性能、データサービスを提供すること。それが『XtremIOの美学』です。

高速Diskの特性を生かし,コントローラーのメモリーをデータキャッシュとして利用しない「キャッシュレスアーキテクチャ」の採用、Flashには宿命のガベージコレクション処理をSSD側に完全にオフロードすることで、性能が利用容量に全く影響しない実装の採用、常にインライン処理のデータ削減機能でSSDへの書き込み・摩耗を極端に抑える実装、しかも性能処理を行うコントローラは完全Active/Active、要求性能に応じてスケールアウトすることで処理性能をリニアに増やすことが可能。All Flashの特性や可用性への考慮点をとことん追求し、従来型のAll Flashストレージでみんながあきらめてきた性能と機能性のトレードオフを完全に克服しているストレージなんです。

ayas:今までのストレージアーキテクチャのダウンサイド、をFlash Diskメインで考えることによって可能にした、ということですね!

M-Itchy:まさしくその通り!『重複排除機能を使うとパフォーマンスが悪くなる』という従来のセリフはXtremIOには必要ありません。また、XtremIOには従来のストレージのようなRAIDの設計やキャッシュヒットといった概念がない。つまり、『IOパターンによって性能がいい時と悪い時がある』というのがXtremIOにはない。どんなIOパターンでも予測可能な性能を提供できる。実際XtremIOスペックシートに記載されている性能値は、他社のストレージが「最大値」を公表するのに対して、『性能保障値』の表示です。誰がどんな時に、どんな風に使っても、少なくともこれだけの性能が出ます、と言い切れる。そもそも機能性と性能性を天秤にかける必要なんてない。両方手にできるのですから。Flash Storageとしてのぶれない美学を進めることによって、それまで無意識にできないと思っていたことを可能にしてしまった、まさにパラダイムシフトなストレージなのです。

 

ささるストレージ

ayas:そんな最強ストレージがついに機能追加ってことなら空でも飛ぶ勢いですね・・・

M-Itchy:あくまでストレージなので地に足はついてますよ。先ほどちらりとお話したように、今ハードウェア面ではより手ごろなモデル(価格的にもシステム的にも)をX2-Tで提供し、エンタープライズ系だけでなくミッドレンジ系へも間口を広げ、ソフトウェア面では待望のReplication機能を備えることによって災対観点でのXtremIO導入の可能性も広げた、もっとXtremIOを沢山の人に使ってもらおう、ということです。(前述記事

ayas:ではFlash Diskの性能を一番に考え、そのためにすべてのアーキテクチャを構築してきたXtremIO。これからどこに行くのでしょうか。MTEXIO8.JPG.jpg

M-Itchy:速いだけのストレージであれば世の中にいくらでもあります。Flashが世に登場した当初は皆がそれを目標に開発をしてきた。でもXtremIOはそれだけじゃない。どんなお客様にも『ささる』ストレージになるし、今回のX2-T6.1でその『ささる』領域がぐっと広がる。

すべてのお客様にXtremIOを使ってもらって、触ってもらいたい!大規模顧客でも、ミッドレンジでも、データベース系であろうと金融系であろうと、一度XtremIOを触ってもらえば絶対に好きになってもらえる自信はあります。ぐっとくるポイントが必ずありますから。

ayas:じゃ行き着く先はストレージはすべてXtremIOの世界ですか!

M-Itchy:いやいや!でも、今後もどんどん機能追加をし、、且つ性能へのトレードオフを発生させない、その結果、現時点ではXtremIOにはとがったストレージのイメージがあるけれど、それが業界の標準、当たり前のストレージになっていくのではないかと考えています。

 

 

『自分の担当するプロダクトに情熱をもっていたいじゃないですか』優しい笑顔の中にあるのは揺るぎないXtremIOへの愛情とその技術への信頼。ストレージスペシャリストよりもジェネラリストでいたいと語るM-Itchyさんは、まさにXtremIOだからこそストレージのスペシャリストになってしまった、そうやってこれからもXtremIOとともに歩み続けていくのだと思いました。

なんだかんだでIsilonianTechも始めて4ヶ月で第6回になりましたが、今回はIsilonとElastic Stackについてご紹介します。

通常ですと、Elastic Stackというキーワードの際は、Isilonはデータレイク基盤としてデータを貯める側になるのですが、今回はIsilonのsyslogを解析するための基盤をELK(Elasticsearch, Logstash, Kibana)で構築してみようという内容です。

(データレイクを期待されたかたは、ごめんなさい。UDS事業本部の営業/SEでご説明に伺います。。)

 

ISLN_Kibana.png

 

 

Elastic Stackについては改めてご説明することは無いと思いますが、大まかな流れとしては、LogstashでIsilonのsyslogを取り込みElasticsearchに格納してKibanaで可視化します。

今回は、テストするにあたり下記の環境を用意しました。最低限、ELK用にLinuxを1台とIsilonクラスタを準備します。Isilonはシミュレータや以前の連載でご紹介したIsilonSD Edgeでも問題ございません。

 

env.png

           Kibana、Elasticsearch、Logstashのロゴは良い感じのデザインですね(https://www.elastic.co/brand

 

 

 

 

Isilon側の設定

Isilon側の設定としてLogstashにsyslogを飛ばす設定が必要になりますので、先ずはGUIもしくは下記コマンドでconfigに関するauditとsyslogを有効にします。

sdedge-1# isi audit settings global modify --config-auditing-enabled=true

sdedge-1# isi audit settings global modify --config-syslog-enabled=true

sdedge-1# isi audit settings global view

Protocol Auditing Enabled: No

            Audited Zones: -

          CEE Server URIs: -

                 Hostname: -

  Config Auditing Enabled: Yes

    Config Syslog Enabled: Yes

 

次に、syslog.confを編集していきますが、/etc配下に存在しているsyslog.confは直接編集しないでください。Isilonはクラスタ型のストレージなので、/etc/mcp/templates/syslog.confを編集することによって自動的に各ノードの/etc/syslog.confが変更されます。なお、syslog.confは事前にバックアップを取得してから編集します。

sdedge-1# cp /etc/mcp/templates/syslog.conf /etc/mcp/templates/syslog.conf.bkup

sdedge-1# vi /etc/mcp/templates/syslog.conf

!audit_config

*.*                                             /var/log/audit_config.log

*.*                                             @cent7.isilon.local

!audit_protocol

*.*                                             /var/log/audit_protocol.log

*.*                                             @cent7.isilon.local

 

次に、syslogのポート番号を変更するために/etc/servicesを編集します。なお、/etc/servicesはmcpに存在しないため各ノードで編集しますが、こちらもバックアップしてからの編集を推奨いたします。今回、ポート番号は8514としました。

sdedge-1# vi /etc/services

~~~~

syslog          8514/udp

 

syslogdを再起動します。なお、isi_で始まるコマンドはサポート用のコマンドとなり影響範囲も大きいので、くれぐれもご利用の際はご注意ください。

sdedge-1# isi_for_array "killall -HUP syslogd"

 

以上でIsilonの設定は終了です。

 

 

 

ELK(Elasticsearch, Logstash, Kibana)の準備

続いて用意したLinuxにElasticsearch、Logstash、Kibanaをセットアップしていきます。なお、Elasticsearch、LogstashにはJava8が必要ですので予めJavaをインストールしておく必要があります。

インストールに関しては、yumリポジトリを設定されても良いですしwgetやcurl等でダウンロードしてからインストールでも構いません。

 

Elasticsearchのセットアップ

私のほうでは、下記のとおりcurlを使ってelasticsearchのrpm(現時点での最新版は6.2.2でした)をダウンロードしてインストールしました。

 

1. Elasticsearchのインストール

[root@cent7 ~]# curl -k -L -O "https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.2.2.rpm"

[root@cent7 ~]# rpm -i elasticsearch-6.2.2.rpm

 

2. elasticsearch.ymlの編集

/etc/elasticsearch配下のelasticsearch.ymlを編集することによって、クラスタ名、ノード名、ポート番号など変更できますが、今回の構成では、elasticsearch.ymlの編集は不要です。

 

3. Elasticsearchの起動

[root@cent7 ~]# systemctl enable elasticsearch.service

[root@cent7 ~]# systemctl start elasticsearch.service

 

 

Logstashのセットアップ

次に、Logstashのセットアップを実施します。

 

1. Logstashのインストール

[root@cent7 ~]# curl -k -L -O "https://artifacts.elastic.co/downloads/logstash/logstash-6.2.2.rpm"

[root@cent7 ~]# rpm -i logstash-6.2.2.rpm

 

2. logstash.confの作成

インストールディレクトリのconf.d配下にlogstash.confを作成します。(一般的には/etc/logstash/conf.d/logstash.confです)

Logstashはデータを整形できますが動作確認がメインですので今回はinputとoutputのみでfilterは省略します。格納先はElasticsearchを設定します。

[root@cent7 ~]# vi /etc/logstash/conf.d/logstash.conf

~~~~~~

input {

  tcp {

    port => 8514

    type => syslog

  }

  udp {

    port => 8514

    type => syslog

  }

}


output {

  elasticsearch{

    hosts => ["cent7.isilon.local:9200"]

  }

  stdout{

    codec => rubydebug

  }

}

~~~~~

 

3. Logstashの起動

[root@cent7 ~]# systemctl enable logstash.service

[root@cent7 ~]# systemctl start logstash.service

 

 

Kibanaのセットアップ

 

1. Kibanaのインストール

[root@cent7 ~]# curl -k -L -O "https://artifacts.elastic.co/downloads/kibana/kibana-6.2.2-x86_64.rpm"

[root@cent7 ~]# rpm -i kibana-6.2.2-x86_64.rpm

 

2. kibana.ymlの編集

[root@cent7 ~]# vi /etc/kibana/kibana.yml

~~~~~

elasticsearch.url: "http://cent7.isilon.local:9200"

~~~~~

 

3. Kibanaの起動

[root@cent7 ~]# systemctl enable kibana.service

[root@cent7 ~]# systemctl start kibana.service

 

 

 

Kibanaからsyslogの可視化

 

1. Kibanaへのアクセス

ブラウザでKibanaをインストールしたホスト名の5601ポートにアクセスします。(今回の例では、http://cent7.isilon.local:5601/)

Kibana_dashboard.png

 

2. インデックスパターンの作成

画面左側の「Management」タブから「Index Patterns」を選択して[Index pattern]を入力します。

Kibana_index1.png

 

[Time Filter field name]フィールドから"@timestamp"を選択して「Create index pattern」を選択します。

Kibana_index2.png

 

 

2. ログの確認

画面左側の「Discover」を選択しログが表示されているか確認します。

Kibana_discover.png

 

 

 

いざ、実行

無事にIsilonのsyslogが確認できたら、Isilonからのsyslogをタイムリーに拾えるかテストします。

 

1. Isilonからテストアラートの発行

Isilonからテストアラートを飛ばして、正常に表示されるか確認します。OneFS web administration interface(Web UI)から実行する場合は「Cluster Management」、「Events and Alerts」と辿っていき「Send Test Alert」の[Test Message:]フィールドに文字列を入力して「Send Test Alert」をクリックします。

OneFS_alert.png

 

2. Kibanaから確認

テストアラートが受け取れているかKibanaから確認します。IPアドレス部分はマスク(モザイク処理)しておりますが"host:"フィールドはIsilonクラスタのIPアドレス、"remote_addr:"フィールドは、テストアラートを実行したクライアントPC(Web UIにアクセスしているマシン)のIPアドレスが表示されます。また、"message"フィールドに、入力した文字列(下記の例では、"hoge 1"、"hoge 2"、"hoge hoge"と3回アラートを発行してみました。)が表示されることが確認できます。

Kibana_OneFS_alert.png

 

 

 

バックナンバー

IsilonianTech 第1回 Isilonとオープンソース ~REX-Ray編~

IsilonianTech 第2回 Isilonとオープンソース ~OpenStack Manila編~

IsilonianTech 第3回 Isilonとオープンソース ~Isilon Data Insights Connector~

IsilonianTech 第4回 Software Defined Storage ~IsilonSD Edge~

IsilonianTech 第5回 Isilonとオープンソース ~Isilon-POSH~

IsilonianTech 第6回 Isilonとオープンソース ~Elastic Stack編~

IsilonianTech 第7回 Isilonとデータアナリティクス ~Cloudera編~

IsilonianTech 第8回 Elastic Cloud Storage (ECS) ~ECS Community Edition~

IsilonianTech 第9回 ISILON + ECS = UNLIMITED ~Isilon CloudPools~

 

安井 謙治

Dell EMC Unstructured Data Solutions

UDS事業本部 SE

エキスパートを捕まえて旬な話題についてお話いただくMeet The Expert !

今回は、とうとうここでもREST APIへの歩み寄りが始まった!この話題にぴったりのお二人を直撃。

 

goboucchiさん:知る人ぞ知るスイッチエキスパート。日本最大級のSANネットワークを構築、管理、モニタ―して安定稼働させる神業の持ち主。

KUROさん:フォーラムでもおなじみ。数々の神業ブログを投稿。スイッチサポートのエキスパート。

 

 


それぞれのREST API

ayasブログに投稿してくださったようにリリースは4月になるようですがFOSで8.2もRESTAPIが使えるようになるんですね。

2.JPG.jpg

goboucchiさん:ユーザの立場からするとREST API は便利です。まずいちいち機器にログインしなくても指示が出せる。管理運用している立場からすると機器にログインしなくていいのはほんとに楽ですよ。

しかもコンピュータの理解しやすい結果が返ってくるので、今までのように戻り値でいくつか条件をつけて作りこんでいたスクリプトよりも信頼度が増すし、しかも手早くできる!以前FOSのバージョンアップでコマンド戻り値が変わってしまいスクリプト構成も変えなきゃいけない事態にあたったことがありますが、そんなことにはならない。

 

4.JPG.jpg

KUROさん:確かに。何十というゾーン変更を常時行うような方(goboucchiさんをじっと見つつ)にとっては実行時間の短縮も期待できますよね。

障害対応をする側として使い方くらいは知っておかないといけないと思って試してみましたが運用管理だけでなく障害対応にもこれは使えそうだなと。それまで必要だった結構地道な確認方法、つまり、障害発生➡機器にログイン➡エラーカウント確認➡被疑箇所特定という流れを、REST APIで要所のパケット状態を常時管理さえしておけば(フレームロスト確認などで)障害箇所の絞りこみがいち早く出来るようになるでしょうから。




マインドセットとREST API

ayas :そんなに便利なのであれば将来的にすべてREST APIになっていくのでしょうか?

goboucchi:大まかな流れとしてはそうでしょうね。ただそれでもプロダクト独自の知識は必要です。

REST APIを使うといっても対象機器はそれぞれに『お作法』を持っていますからね。スイッチでいえばゾーニング変更するときの必要情報や命令の順番を知らないとREST APIでその指示は出せない。そういう『お作法』を理解したうえで、いちいちコマンド発行して30分かけてやっていたゾーン変更を信頼性の高いスクリプトを使って1分終わらせる、そういう点でREST APIの魅力が光る。

3.JPG.jpg


KURO:二極化していくだろうと思いますよ。goboucchiさんのように自分でなんでも変更してバシバシやるような人にとってREST APIは便利でお得なツールだし、もしそこで詰まってもそういう方は自分で解決できる。海外ではそういうお客様のほうが多いのでREST API人気も,その情報量も日本のそれより多いでしょう。

一方コンサバティブなお客様にとって作業手順書が彼らに理解できないもの、では問題がある。そういう人にとってREST API の魅力は伝わらない。マインドセットによって期待する便利さ、ツールが重の視点が違いますからね。ただ、さらにITインフラストラクチャが複雑化してくるであろうこれからの時代は、人的ミスが発生しない安全な構成変更、安定運用、もしくは障害発生時の迅速な対応可否が重要視されるでしょう。そうなるとREST APIのような便利でかつ正確なツールはますます重宝されると思います

 

goboucchi:そう、僕らみたいなユーザーにとってREST APIは「便利でお得なわくわくツール」なのです。今までやってた面倒なスクリプティングの時間が10分の1になる。しかもなんか将来性ありそう・・・。OpenStackみたいな基盤構築ソフトでシステム機器のの一括管理ができるようになれば便利ですからね。だからFOSを含め最近の製品ではREST APIへの対応を強化しているのかもしれませんね。

 

ayas :なるほど、UnityでもCLIでできないことがREST APIならできるとかいうことになってますしね。スクリプトに親しんでいる人ならREST APIもハードル低いでしょうし。私も挑戦中ですがエラーばかりで心が折れそうになりました。REST API友の会を作ってもらいたいです。

6.JPG.jpg

 

goboucchi:ははは!友の会で昔から地雷を踏みながらも経験値を上げてきたスクリプト職人たちが情報や経験をシェアすればREST API 人口が増えていくでしょうね。そして誰かがもっと便利なREST APIツールをつくってくれれば友の会はもっともっと広がっていく・・・

 

 

この後もお二人は今まで踏んだ地雷の話でかなり盛り上がったのですが何かと大人の事情があるためここには記載できないことばかり。でもそんなお二人の姿はまさにどんな時でも道を切り開いていく開拓者そのものでした!

Filter Blog

By date:
By tag: