2013年04月24日

有線LANの最新動向。400GbEが2017年頃に

PCに内蔵されている有線LANで一般的なのが1GbE。その400倍になります。
もちろん400GbEはプロバイダや都市間、企業のサーバ内を結ぶネットワークからスタートで、一般家庭に入ってくるのはもっと先ですが、携帯端末の普及でトラフィックが溢れている今、縁の下の力持ちの有線LANについて知るのも重要なのかと思います。


400GbEの標準化は2017年を目標、IEEE標準化グループの米Dellダンブロシア氏
デル株式会社は9日、米Dellのチーフイーサネットエバンジェリストを務めるジョン・ダンブロシア氏による、イーサネットの最新動向に関する説明会を開催した。

 ダンブロシア氏は、IEEEにおいて40ギガビットイーサネット(40GbE)と100ギガビットイーサネット(100GbE)のタスクフォースで議長を務め、約3週間前にIEEEに承認された400ギガビットイーサネット(400GbE)スタディグループでも議長代理を務めている。

 ダンブロシア氏は、「過去にはバンド幅の予測が甘かったため、イーサネットが市場のニーズを満たせなかった時期があった」として、イーサネットの高速化仕様を策定するにあたっては市場を広く見る必要があると説明。世界全体のアクセススピード高速化に加え、モバイルデバイスの急速な普及により、ネットワーク全体の成長率は年58%のペースになっており、現在最速の100GbEでも将来的なニーズを賄うことは難しく、より高速なイーサネットが求められているとした。

 また、「仕様の策定にあたっては、適切なコストで実現することが最も重要」という観点から、スタディグループの立ち上げにあたっては綿密な市場調査を実施し、「将来的には1TbEや10TbEも必要になるのは間違いないが、今取り組むべきは400GbEだという結論に達した」という。

 400GbEの標準化については、2017年ごろを目標にしていると説明。また、製品については仕様がある程度固まった段階で標準を先取りする形で、2016年ごろには登場するのではないかとの見通しを示した。

 400GbEが使われる領域については、ラック内やデータセンター内の数十mという範囲から、メトロエリアを結ぶ数kmといった様々な用途があり、用途に応じてマルチモードファイバー(MMF)やシングルモードファイバー(SMF)、さらには銅線を使う仕様も検討していくと説明。「銅線の時代はもう終わったという人もいるが、私はそうは思わない」としつつも、「個人的な見解としては、SMFが今後は様々な用途に利用されていくのでないかと思う」と語った。

 ダンブロシア氏は、規格にはコストや消費電力、技術的な難度などバランスを取ることが求められており、用途に応じた様々な実装も求められると説明。フォトニック統合やシリコンフォトニクスといった技術については、「400GbEを実現する上での鍵となる技術と言う人もいるが、私個人としては実装の一手段だと考えている」とした。また、「規格はIEEEが決定するのではなく、IEEEで参加者が決定するもの」だとして、標準化にあたってはコンセンサスが必要だという点を強調した
(PC Watchより)


posted by カミガタ at 22:13 | TrackBack(0) | エンタープライズ | このブログの読者になる | 更新情報をチェックする

2012年06月27日

親会社のヤフー自らファーストサーバ障害の損害賠償の支払いを含めた話し合いをユーザー企業と開始

これはスピードあって、誠意ある対処ですね。本当なら。


ファーストサーバ障害:親会社のヤフー自ら補償などの顧客対応を開始

レンタルサーバ事業者のファーストサーバが顧客のメールおよびウェブデータを消失した問題で、ファーストサーバの親会社であるヤフーが、損害賠償の支払いを含めた話し合いをユーザー企業と開始していることがZDNet Japanの取材で分かった。

 ヤフー自身がファーストサーバの顧客に金銭面での賠償を含めた対応を開始している。

 ヤフーによると「個別のお客様に案内をし始めており、最終的には対象となるすべてのお客様と連絡を取る」という。

 ヤフーは「子会社のサービスで発生した障害で多くの方に迷惑をかけ申し訳ない」と話し、事態の復旧を急ぐファーストサーバを全面的に支援するとしている。

 一方、ファーストサーバは電話取材に対して「FAQ以外の事柄に関するメディアの取材に対してはメールと電話で順次対応する」と述べた。
(ZDNet Japanより)
posted by カミガタ at 11:54| Comment(0) | TrackBack(1) | エンタープライズ | このブログの読者になる | 更新情報をチェックする

2012年06月26日

ファーストサーバ事件に見る騒動への違和感と「教訓」

今回の騒動では、「データ復旧が〜」「損害賠償が〜」に話題が集中しています。確かにデータを取り戻せないのは痛い。サーバ上に置かれていたデータは膨大で、かつデータベースのような動的に変化するデータだったので、「ユーザ側でバックアップ取っとけよ」という主張にも限界があると私は思います。
けれど、データ復旧に話題が行くばかりで、ではこれからどうするの?
自分は第二第三のファーストサーバ事件が起こる可能性は高いと思います。
今回のきっかけは、ちょっとの人為的ミスでしたから。
やっぱり重要なのは「教訓」。

本文中でも、ファーストサーバの暫定的対策として以下のことが書かれています。
1)サービス再開に必要な場合、緊急メンテナンスが必要な場合などやむを得ない場合を除き、当面の間はメンテナンス作業を停止。2)メンテナンス運用手順を修正し、対象外サーバの確認作業を追加。3)通常のバックアップ以外ではバックアップ領域に修正を加えられないように仕様を修正。


これは、失敗とその後の再発防止、そして他のサーバ会社や企業内ネットワークでの事故予防にとって重要な指標になるのではないでしょうか。
今回のファーストサーバの事件はそれを思い起こさせてくれたと感じます。


ファーストサーバ、大規模障害の概要と原因を中間報告――複数要因が重なりデータ消失

Yahoo! JAPANの子会社で、レンタル・サーバ・サービスを展開するファーストサーバは6月25日、同月20日に発生した同社サーバの大規模障害について、その概要と原因の中間報告を発表した。また併せて、障害発生後、ファイルの誤参照の障害も発生していたことも明らかにした。

 中間報告によると、同社は6月20日17時ごろ、メンテナンス作業の一環として、更新プログラムを利用した脆弱性対策を特定のサーバ群に対して実施した。だが、1)更新プログラム自体に不具合があったことに加え、2)検証環境下での確認による防止機能が十分に働かなかったことと、3)メンテナンス時のバックアップ仕様の変更が重なり、バックアップ・データの消失を含む今回のデータ消失が発生したと説明する。

 上記の3つの要因が重なったことにより、今回の大規模障害とそれに伴うデータ消失が発生したもよう。ファーストサーバでは、それぞれの障害原因について、次のように述べる。

●障害の原因
 同社では、脆弱性対策のためのメンテナンスが必要となる都度、メンテナンスのための更新プログラムを作成していた。今回も更新プログラムを作成した。そのプログラムの記述において、ファイル削除コマンドを停止させるための記述漏れと、メンテナンスの対象となるサーバ群を指定するための記述漏れがあったとしている。

 メンテナンスに際しては、検証環境で動作確認を行うという手順が定められていた。だが、プログラム実行後の動作確認を行う対象は、当該メンテナンス対象サーバ群を確認すれば足りると認識し、検証環境下で対象サーバ以外に影響が及んだことの確認がないまま、動作確認上は問題なしと判定し、本番環境での実施が行われた。

 メンテナンス時のバックアップ仕様については、同社ではシステムを含むデータのバックアップは毎朝6時に取得していたという。しかしながら、脆弱性対策のメンテナンスに関しては、対象サーバ群とそのサーバ群のバックアップ領域に対して同時に更新プログラムを適用するという構造で実施していた。そのため、今回のメンテナンス実施において、対象サーバ群のデータ消失と同時にバックアップ領域のデータも消失したという事象にいたったとしている。

 脆弱性対策のためのメンテナンス実施後にハードウェア障害が発生し、バックアップに切り替えた途端に脆弱性対策が講じられていないシステムに戻り、脆弱性対策がなされていないシステムが動き続けていたということが過去に発生。その反省のもと、バックアップをしてあるシステムについても、メンテナンスを同時に実行する仕様に変更したという。

 同社はまた、暫定対策についても明らかにしている。1)サービス再開に必要な場合、緊急メンテナンスが必要な場合などやむを得ない場合を除き、当面の間はメンテナンス作業を停止。2)メンテナンス運用手順を修正し、対象外サーバの確認作業を追加。3)通常のバックアップ以外ではバックアップ領域に修正を加えられないように仕様を修正。

 なお、第三者による事故調査委員会を6月30日までに立ち上げ、事故要因を徹底究明し、再発防止策を策定するとしている。

●ファイルの誤参照の障害
 ファーストサーバによると、共有サーバと専用サーバの復旧作業において、それぞれで障害が発生していたという。

 同社ではデータ消失の後、データ復旧作業を実施。6月21日9時ごろにデータの復旧プログラムにより消失データを復旧し、リカバードファイルとして顧客にデータを提供した。

 だが、専用サーバの顧客より、専用サーバ内において情報にアクセス権限を有していなかった者からも参照できる状態になっているとの報告があり、リカバードファイルの提供を22日21時ごろに停止。状況の確認を行ったところ、専用サーバ内において、アクセス権限を有していなかった情報についても参照が可能な状態にあったことが判明したという。

 上記の問題発覚を受け、共有サーバにおいてもリカバードファイルの提供を即時停止し、現在状況の確認を行っていると説明している。なお、影響範囲も現在調査中だとしている。

 同社は25日より今回の大規模障害に関するFAQサイトを立ち上げている。障害詳細やサポート、今後の対応、損害賠償などのカテゴリ別に情報が提供されている。
(Computerworldより)
posted by カミガタ at 09:23| Comment(0) | TrackBack(2) | エンタープライズ | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は180日以上新しい記事の投稿がないブログに表示されております。