bash脆弱性の対応における注意

みなさんは大丈夫なのかもしれませんが、2点ほど危ないなあと思ったので書き留めておきます。

9月24日、bashにCriticalな脆弱性が発見されCVE-2014-6271として注意喚起が行われた。これに対してパッチは公開されたようですが、完全に対応が出来ていなかったため、CVE-2014-7169として新たに注意喚起が行われている状況です。

そして、9月26日、CVE-2014-7169に対応したパッチが公開されセキュリティアドバイザリーがなされています。

こうやって近しい日付で2段階に注意喚起が行われているため昨日の段階で対応された方は次の日に同じ話題となっていても同じ脆弱性のことを言ってるんだなと安心しきってしまう恐れがあるように思います。4桁目を変えてはありますが番号も似ているし危ないなあと思った次第です。

対応するパッチに不備があると、注意喚起も新規に発行されるようになっているんだとは思いますがこのあたりをちゃんと認識しておく必要があるようですね。

■CVE-2014-6271
https://access.redhat.com/security/cve/CVE-2014-6271
redhatのerrata発行(セキュリティアドバイザリー)
https://rhn.redhat.com/errata/RHSA-2014-1293.html

■CVE-2014-7169
https://access.redhat.com/security/cve/CVE-2014-7169
redhatのerrata発行(セキュリティアドバイザリー)
https://rhn.redhat.com/errata/RHSA-2014-1306.html

また、もう一つの注意点として
# yum update bash
などで対応されると思いますが、例えばパブリックミラーにより同期が間に合わず修正版が上がっていないところも見受けられます。アップデートは必要がないと出ていても別のミラーには存在していることがありますので7169に対応しているバージョンなのかどうかをちゃんと確認することをおすすめします。

OS(x86_64) CVE-2014-6271 CVE-2014-7169
RHEL5 bash-3.2-33.el5.1 bash-3.2-33.el5_11.4
RHEL6 bash-4.1.2-15.el6_5.1 bash-4.1.2-15.el6_5.2
RHEL7 bash-4.2.45-5.el7_0.2 bash-4.2.45-5.el7_0.4

「小学生でもわかるSDN」勉強会やりました

囲碁の勉強会も相当無茶振りだったのですが、今回のお題もかなり無茶です。

とはいえそれなりに頑張るのがプロサラリーマンってもんです。

それなりな資料を作ってそれなりにごまかせたので資料を公開しておきます。

後半は著作権上問題がありそうな図とかもあるので非公開です。ごめんなさい。

DMM.comの事例で知る、データセンターでの回線確保

こんにちは、ゲストブロガーのあきみちです。

前回記事で紹介したように、DMM.comにとってのデータセンターは「サーバや通信機器を置く場所を借りるところ」です。セキュリティが確保された場所で、とまらない電気が供給され、適切な温度管理が行われた不動産なのです。

そのように表現すると、「あれ?iDCってインターネットデータセンターだよね?ネットワークは???」と疑問に思われるかたも多いと思います。そうなんです。データセンターに置かれた機器と外部との通信をどのように実現するのかも、データセンターを利用するうえで非常に大事なポイントなのです。

しかし、ネットワークそのものをデータセンターが直接提供しているかというと、必ずしもそうとは限りません。今回は、DMM.comが行っている手法にフォーカスしつつ、データセンター利用者が回線を確保することに関して紹介します。

データセンターでの通信手段確保

データセンターは非常に特殊な不動産事業であり、通信事業者であるとは限りません。そのため、データセンター事業者が直接通信回線を提供するのではなく、データセンター事業者と提携した通信事業者が回線部分を担うこともあります。

さらにいうと、データセンターを利用する顧客によってどのような通信回線が必要となるのかも違います。インターネットに直接接続された回線を必要とする顧客もいれば、広域な社内ネットワークの延長線上にデータセンターのコロケーションを位置づけて運用している顧客もいます。

そういった事情もあり、データセンター事業者が直接通信回線を提供するというよりも、むしろデータセンター事業者に構内配線の依頼をするといった形になりがちです。では、実際にどういう用途なのかの例を紹介していきましょう。

同じデータセンター内に通信事業者が入居している場合

様々な事業者が入居しているデータセンターもあります。

たとえば、データセンター内にIX(Internet eXchange。別記事で解説します)であったり、インターネットプロバイダやインターネットサービスプロバイダ、長距離通信を行うキャリアが入居している場合もあります(長距離通信キャリアがデータセンター事業者という場合もあります)。

IXが入居しているデータセンターを利用している顧客は、IX事業者までの構内配線をデータセンター事業者に依頼することで、他の事業者とのBGPによるピアリングを行える環境を手に入れます。同様に、データセンター事業者に構内配線を依頼することで、インターネットプロバイダなどからインターネット接続サービスを購入することもできます。

データセンターでの構内配線のイメージ
データセンターでの構内配線のイメージ

どのような事業者が、そのデータセンターに入居しているのかが、データセンターそのものの価値を上昇させる要素になるのです。各種事業者との接続が構内配線のみで行えるのは、「便利なデータセンター」なのです。

そして、そういった「便利なデータセンター」に様々な重要設備が集中しがちです。経済原理によって構築された「情報の密集地帯」となっているデータセンターも存在するわけです。

さて、次に、DMM.comの東京データセンター1での事例を見てみましょう。

東京データセンター1にあるコアルータ
東京データセンター1にあるコアルータ

まず、以下の写真がDMM.comの東京データセンター1で運用されているコアルータです。Juniper MX480が2台構成になっています(排気の関係などから1ラックに積まれてしまっているようです。「本当は別ラックに分けた方がいいのだけど。。。」らしいです)。

この写真にあるデータセンターでは、構内配線を経由してピアリングやトランジットを行っています(ピアリングやトランジット、IXなどに関しては別途記事を書く予定です)。同じデータセンター内にエリアを借りている他の事業者と構内配線で接続しているのですが、それが「インターネットとの接続」になるのです。そのため、通信機器を見ても単に普通に光ファイバで繋がっているだけのように見えます。

なお、余談ではありますが、写真を撮影した後に、「あ!養生テープタグのままだった!ツチノコブログにそのまま写真を掲載しちゃうのは多少恥ずかしいかも」と言っていましたが、その後、「格好悪い部分も含めて晒すのが漢」とか意味不明な主張をされていました。

他の場所へのダークファイバ

構内配線で他の組織に繋がることによって外部との通信手段を確保する手法は、データセンターの外との通信を他の事業者に外注することを意味します。

しかし、その方法では、間に他の事業者が提供するルータなどの通信機器が介在することになりがちです。目的によっては、間に他の事業者が提供するルータなどを経由させずに直接自社が運用する機器同士を接続したい場合もあります。

そのような場合には、ダークファイバを借りるという手法が採用されることがあります。ダークファイバは、長距離の光ファイバをそのまま借りれるサービスです。光が通っていない状態で提供されることからそのように呼ばれています。

ダークファイバを使って通信を行える距離は、その光ファイバに接続された通信機器のネットワークインターフェースによって変わってきます。たとえば、10GBASE-LRを使った場合には最大10km、10GBASE-ERを使った場合は最大40kmまでの通信が可能です。10km以内に存在しているデータセンター同士であれば10GBASE-LRで、40km以内に存在しているデータセンター同士であれば10GBASE-ERで、そのまま直接接続できるのです。

DMM.comは、ダークファイバを10GBASE-ERで利用して東京都内のデータセンター同士を接続しています。このダークファイバをJuniperによるファブリック(ファブリックに関しては別途記事を書く予定です)の一部であったり、バーチャルシャーシを構成する回線として使ったりしています。通常の長いシングルモードファイバとしてダークファイバをそのまま利用した形です。

EX 4200のバーチャルシャーシ機能をダークファイバで
EX 4200のバーチャルシャーシ機能をダークファイバで

DMM.comでは、そのような運用を行っていませんが、たとえば、WDM装置を用意して複数波長を一本のダークファイバに乗せるといった用途も考えられます。

その他の方法

データセンター外との通信回線がダークファイバに限定されているわけではありません。

ダークファイバ以外にも、長距離伝送サービス(Optical Transport Networkを用いた数百〜数千kmの長距離伝送など)の購入や、IPパケットの中にIPパケットをカプセル化したうえでそれを暗号化したVPN(Virtual Private Network)の利用といった手法でデータセンター外部との通信回線を確保することが可能です。DMM.comでは、東京のデータセンターから九州のデータセンターまでVPNを利用した接続を行っています。

その他、データセンター事業者がネットワークの提供を行う場合もあります。たとえば、データセンターが持っているIPアドレスブロックが顧客に提供されるといったサービスもあります。データセンター事業者がインターネット接続を提供する上位プロバイダになるというものです。

最後に

ここで紹介しているのは、主にDMM.comが採用している手法です。データセンターと外部の通信手段を確保する方法は、この他にも様々なものがあります。何をしたいかによって回線を確保する方法も変わりますし、新しい技術やサービスが産まれることによっても色々変わってきます。

OSI参照モデルの7層構造を念頭に、電源や配線が「レイヤー0」と呼ばれることもありますが、インターネットはこのような物理的な設備や回線によって構築されているのです。ユーザとして使う場合のインターネットは「繋げば使えるもの」であるように見えがちですが、インターネットそのものを構成している物理的な機器や回線を取り巻く商習慣は意外と生々しいものだったりします。

インフラエンジニアたる者のたしなみ

みなさんもご存じのネックストラップ

こちらをご覧ください

IMG_1092

先がない。。。
※分かりずらいですが本来はこの先にカードホルダー部があるんです。

カードホルダー部分がごっそりと無くなっています。幸い警察に届けられ手元に戻ってきたのですが悪用されないとも限りません。拾ってくださった方。本当にありがとうございました。この場をお借りしてお礼申し上げますm(_ _)m

気をつけなきゃいけないということで、何名かのエンジニアの巻き取りリールの紐部分を調査してみたところ、

こんなんでました。

IMG_1094

確実にもうすぐ切れます。時間の問題です^^;

これはなんとか対策しなくちゃいけないねと考えていたところ

ある、エンジニア(shinonome)から

「インフラエンジニアたるもの冗長化必須じゃないですか( ̄∇ ̄)v ドヤッ!」と

こんなん見せられました。

IMG_1089

 

かっけー!!!(東京ドームの総監督風)

リールを冗長化してるやつがいるなんて

すごいというかなんというか職業病ということで片づけることにします。

みなさんも紐の確認してみてくださいね。同じような方いるかもです。

それではさようなら。

追記

スケールアウト/分散型

IMG_1144

NUMAとメモリとゲームとサーバ

艦これ」といえばDMMのゲームと言われるほどにまでなりましたが、「城コレ」が今度は控えているようです。約30万人の方が事前登録してくださったという嬉しい悲鳴がところどころで聞かれます。そしてツチノコ部隊も全体の安定稼働へ向けて色々と対応しています。ところで、こういうオンラインゲームは、可愛いキャラクターもさることながら、ブラウザの裏でインターネット越しに必死に動いている「黒子」のようなものたちがいます。いわゆる「ゲームサーバ」と呼ばれるものです。

ゲームサーバは、その基本構成としておおまかに「アプリ(フロント)サーバ」と「データベース(バックエンド)サーバ」に分かれます。今日はその中でも「データベースサーバ」についてのお話です。

DMMでは大抵のデータベースサーバにLinuxとMySQLを使っています。そのデータベースエンジンにInnoDBというのがありまして、設定項目としてメモリ上にバッファをするという設定を行うことができます。

innodb_buffer_pool_size = 100G

例えば、メモリを128GB搭載したサーバでバッファ用に100GBのメモリを割り当てるとします。さて、実際のメモリの割当はどのようになるでしょうか。最近のXeonを搭載したサーバとして考えてみます。実はCPUの個数により、そのメモリの割り当てられ方が変わってきます。というのも、昔と違い今はメモリのコントローラがCPUに内蔵されているからなのです。

  • シングルCPU構成の場合

すべてのメモリがCPUと直接つながっているので、特に気にする事はありません。

  • マルチCPU構成の場合

CPU0とCPU1…とにそれぞれメモリがつながっています。例えば先ほど128GBとしたメモリが2CPU環境にあるとしましょう。そうするとCPUにごとに64GBのメモリがつながっている事になります。標準ではLinuxはプロセス毎にそのプロセスが動いているCPUにつながったメモリを利用しようとします。つまり、先ほどの100GB割り当てが、MySQLのプロセスが動いている片方のCPUに偏ってしまうのです。その結果、片方のメモリがMySQLに食いつぶされ、そこにもともといたデータがSWAPに吐き出されます。もう片方のCPUにつながっているメモリに空きがあっても、です。

少し詳しい話にしましょう。最近の共有型のマルチプロセッサシステムアーキテクチャは、NUMA(Non-Uniformed Memory Access)というものです。これは、CPUとメモリのまとまりを「ノード」と呼びます。先の例では、CPUと64GB分のメモリのまとまりが”ノード”です。

Linux OS上でプロセスが起動すると、そのプロセスはCPUに割り当てられます。CPUとメモリがまとまっているので、プロセス自体のデータは同じNUMAノードのメモリに置かれます。
先の例の2CPUの環境MySQLが起動したあとメインスレッドがCPU0に割り当てられたとして、そのCPUにぶら下がる64GBのメモリにMySQLのデータが置かれます。しかし、バッファデータのサイズだけで100GBあるので、NUMAノードの64GBをいずれ食いつぶします。そうなると、同じNUMAノード上にある他プロセスのデータがメモリから溢れます。他NUMAノードのメモリはデフォルトではOSが割り当てをしない状態になっているため、あふれたものはスワップへ送られます。もともと64GBのメモリ上にあるものなのでスワップアウトするデータ量も大きくなる傾向があります。なので実際のところスワップが埋まってしまう可能性が非常に高いです。

では、どうすればこの偏りやスワップアウトを抑えることができるのか。

numactl --interleave=all ${CMD}

NUMAをOSからコントロールするnumactlというコマンドがあります。
–interleaveオプションは割り当てるNUMAノードを指定します。上記の例では”all”となっているため、すべてのNUMAノードに割り当てを行うことを意味します。

cat /proc/`pidof ${PROCESS}`/numa_maps

こちらのコマンドで、NUMAに対するプロセスの状況が見られます。
とはいえ、見るのは大変なので、下記のページを参考に、Perlスクリプトを使ってみましょう。
http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/
numa-maps-summary.pl というスクリプトです。って、実はこれ2010年の記事なんですよね。知りませんでした。

実際にスワップアウトしてスワップを喰い潰してしまったサーバがこちら

[root@srv3053 ~]# perl numa-maps-summary.pl < /proc/`pidof mysqld`/numa_maps;free
N0        :     16132628 ( 61.53 GB)
N1        :     12288264 ( 46.88 GB)
active    :     26922666 (102.70 GB)
anon      :     28420892 (108.42 GB)
dirty     :     28420892 (108.42 GB)
mapmax    :          157 (  0.00 GB)
mapped    :         1373 (  0.01 GB)
             total       used       free     shared    buffers     cached
Mem:     132112264  126602604    5509660          0     142040   10854736
-/+ buffers/cache:  115605828   16506436
Swap:      2097136    2097136          0

同じサーバで、numactlを設定したのがこちら

[root@srv3053 ~]# perl numa-maps-summary.pl < /proc/`pidof mysqld`/numa_maps;free
N0        :     14679063 ( 56.00 GB)
N1        :     13763886 ( 52.51 GB)
active    :     26950881 (102.81 GB)
anon      :     28441601 (108.50 GB)
dirty     :     28441601 (108.50 GB)
mapmax    :          158 (  0.00 GB)
mapped    :         1410 (  0.01 GB)
             total       used       free     shared    buffers     cached
Mem:     132112264  125522400    6589864          0     141764    9805148
-/+ buffers/cache:  115575488   16536776
Swap:      2097136          0    2097136

設定前はNUMAノード分の64GBに近く偏っていたものが、設定後は分散されているのがわかります。
上記のようにプロセスがどかっと大きなメモリを割り当てることでスワップアウトしてしまう現象を”Swap Insanity”といいます。
そして先のブログ記事にもありますが、mysqldのinitスクリプトを改造して、numactlを埋め込んでしまうという手を使うことで、回避ができます。