［速報］EMC、PCIe接続で共有型フラッシュストレージ「DSSD D5」発表。レイテンシ100マイクロ秒、1000万IOPS
DSSD D5の特長は、PCIeインターフェイスを用いつつ複数のサーバのストレージを集約できる点にあります。これにより、内蔵ストレージのように広帯域で低レイテンシな性能を実現し、共有ストレージアレイのように電源やインターフェイス、ストレージの冗長性を高めることで高い可用性を実現しています。 これを実現したのが、DSSD D5に搭載されたPCIe Switched Fabricです。ストレージ側には冗長化された48のPCIeケーブルを挿すコネクタを備えたI/Oカードが搭載され、最大48台のサーバのPCIeホストカードとケーブル接続できます。 ストレージ内部のフラッシュメモリモジュールも冗長化されたNVMeインターフェイスで接続されており、ストレージに搭載されたPCIeのI/Oカード内のスイッチによって、サーバからフラッシュメモリモジュールまでダイレクトパスが作られて、非常に高速なアクセスが実
複数プロジェクトを抱えるチームでのデプロイ自動化
複数プロジェクトを抱えるチームでのデプロイ自動化 1つのチームで，10以上のプロジェクト，コードベースを抱える場合にどのようにデプロイの自動化を進めたか，工夫したこと，考慮したことなどをまとめておく． デプロイツールには，Python製のfabricを採用しているが，他のツールでも同様のことはできそう．なお，fabricの基本的な使い方などは既にインターネット上に良い記事がたくさんあるので書かない（最後の参考の項を見てください）． fabricの選択 シェルスクリプトとCapistranoを考慮した． まず，シェルスクリプトは人によって書き方が違うため，統一が難しくメンテナンスコストも高い．また共通化も難しい． 次に，Capistranoは，裏でやってくれることが多く，学習コストも高い．プロジェクトによってはかなり特殊な環境へのデプロイも抱えているため，Capistranoの前提から外れる
Jenkinsでmysqldumpをスケジューリングしてみる - 株式会社オーツー｜スタッフブログ
社内サーバーの状況は、zabbixである程度管理出来るようになったんですが、ちょっと不安になってきたのがバックアップです。 開発用サーバーも含めてmysqlが色々なところで立ち上がっているのですが、このバックアップを楽に出来ないものか、と。 要件的には、 mysqldumpを各サーバーで行う リモートでmysqldumpを行うのではなく、各サーバーでdumpし、出力ファイルを回収する形で。リモート接続を許可していないmysqlもあるので。 各サーバーでdumpしたsqlファイルをまとめて、圧縮して固めておく 圧縮したバックアップは数日間、履歴管理出来るようにする（10日間ぐらい） 対象となるサーバーのリストは簡単に更新出来るようにする 各サーバーにログインする必要がありそうなので、fabricの出番です。 問題は履歴管理。 logrotate等色々とやり方があると思うのですが、練習がてらj
続・ラフなラボ – シェルスクリプトが '> $logfile 2>&1' だらけにならなくて済んだ話
※ 2014-04-26 追記並びに一部コマンド部分の修正を行いました。( > => >> に変更 ) 個人用のチラシの裏のつもりが予想以上に反響いただいていたようで非常にびっくりしております。 ちょっとしたバッチ処理的なものはさくっとシェルスクリプトでやっています。 で、ログをとっておくべくリダイレクトを噛ますわけですが、 スマートに書く方法を調べたのでメモ。 元ネタは @sechiro さんの bashのプロセス置換機能を活用して、シェル作業やスクリプト書きを効率化する でございます。 本当に参考になりました。ありがとうございます。 今までは こんなことやってたわけです。 #!/bin/bash LOGFILE=/tmp/script-log command1 >> $LOGFILE 2>&1 command2 >> $LOGFILE 2>&1 ... >> $LOGFILE 2>&1
Python3に対応したtomahawk 0.7.0をリリース - oinume journal
久々にtomahawkの新しいバージョンをリリース。今回はずっと放置していたPython3対応(Python3.2+)をやっとこさ完了した。 Python3はいろいろ変わり過ぎていてもう諦めようかなーと思っていたんだけど、去年のPyCon APACでsixっていうモジュールを知って、「これ使えばけっこう簡単にPython3対応できるのかー」と思ってやってみた。でも実際はそんな簡単にはいかず、特にunicodeとbytesの違いでけっこうハマってしまったけど。 あとは今回のバージョンから、ReadTheDocsでホスティングしてるドキュメントのテーマをReadTheDocs謹製のものにしてみた。おかげでドキュメントのかっこよさはだいぶ増したはず。 自分的には大量のリモートサーバ操作には最近はFabricを使うことが多くて、もはやtomahawkはほとんど使ってないんだけど、コマンドの出力はや
今年流行りそうな「インフラエンジニア」向けトレンドのまとめ その1 (Blue-Green DeploymentとImmutable Infrastructure編)
あけましておめでとうございます。バズワード評論家 横田でございます。(恐らく)皆様1月6日から出社ですね。お仕事がんばりましょう。 というわけで今年のインフラ業界のバズワードトレンドをまとめてみました。年始の仕事前にどうぞ 《Blue-Green DeploymentとImmutable Infrastructure》今年のインフラ業界の一番のトレンドは「Blue-Green Deployment」と「Immutable Infrastructure」となる気がしています。今までは、サーバの設定を変更する時は、運用中のサーバを変更していましたが、「Blue-Green Deployment」と「Immutable Infrastructure」の考え方は、運用中のサーバの変更するのではなく、新しくサーバ群を用意し、本番環境をそちらに切り替えるという手法を取っております。 手法自体は「Blu
継続的デリバリ／デプロイを実現する手法・ツールまとめ
継続的デリバリ／デプロイを実現する手法・ツールまとめ：DevOps時代の開発者のための構成管理入門（終）（1/2 ページ） バージョン管理や継続的インテグレーションとも密接に関わる継続的デリバリ／デプロイメントの概要や主なツール、経緯、実践事例を紹介。実践手法として「ブルーグリーン・デプロイメント」「Immutable Infrastructure」が注目だ。 完全に自動化されたリリースプロセスが必要となる「継続的デリバリ」とは いよいよ本連載「DevOps時代の開発者のための構成管理入門」も最終回となりました。今回のトピックは「継続的デリバリ」です。 継続的デリバリは、本連載で扱ってきたバージョン管理や継続的インテグレーションなどの単一のプラクティスではなく、それら一連のプラクティスを包含した、ソフトウェアデリバリ全体に対しての「考え方」「アプローチ」といえるものです。 「継続的デリバリ
chef + fabricを用いたクラウドサービス管理 | SmartNews開発者ブログ
ゴクロの大平と申します。はじめまして。 ４月からjoinさせていただいた、特に特記事項の無い平凡なプログラマです。さだまさしが好きです。 SmartNews開発者ブログをご覧になる方々は、サービスの裏側で動作するクローラーや多種多様な機械学習のロジックであったり、フロントエンドのUIの話であったり、サービス固有の話に興味が有る方が多いと存じますが、都合上（原稿の担当順番の都合上）、今回は一般的な話をさせていただきます。 ※先掲の話題については次回以降取り上げられますので、お楽しみに。 一般的な話題とはいえ、大企業とスタートアップでは取り巻く環境や解決すべき課題も異なっていますので、その辺もあわせてお伝え出来ればなと思います。 なお、今回のテーマは、サーバー/ミドルウェアの構成管理ツールとして最近有名になってきた「chef」と「fabric」です。 かなり長文のエントリーになってしまい
Re: Chefに挫折したあなたへ。Fabricのすすめ - Hack like a rolling stone
Chefに挫折したあなたへ。Fabricのすすめ という記事を読んだので、呼ばれてもいないのに勝手に返事を書いてみます。 追記(3/13 10:00): タイトルを typo していたようなので訂正しました。 ちなみに僕のポジションとしては chef 推進派です。 仕事の空き時間や自分の時間で、開発環境の自動化を模索する趣味 chef 使いです。 これまで他の自動化ツールはこれまでほとんど使っておらず、 ミスや手順書のボリューム削減のためにシェルスクリプト化を進めるぐらいでした。 ちなみに、chef を使いはじめる際に、比較検討のために puppet や fabric などのいくつかのツールについて ドキュメントやブログを読みあさった経験はあります。 あと、chef と組み合わせて使うために capistrano を最近使っています。 学習に時間がかかる 同意します。chef のもっぱらの
Chefに挫折したあなたへ。Fabricのすすめ
サーバ設定作業は面倒で間違いを犯しやすいため、Chef/Puppetなどのツールで自動化したいと考えている方は多いと思います。 私もそのような理由からChef(-solo)を習得しようと試行錯誤していました。 その結果、ある程度は動くようになったものの次のような問題があると思いました。 学習に時間がかかる 私は正直、今でもどのファイルに何を書くのかよく分かってないです。 幾分か簡単だと言われるchef-soloでも公式サイトのドキュメントだけではよく理解出来ませんでした。 また、バージョンによる差異なのか目的が異なるのか分かりませんが、ブログ記事を参考にしようとすると十人十色でどれが私に合った手順なのかわかりませんでした。 例え最終的に理解できたとしても、私やあなたが何日もかけて理解できないことはチームのメンバーも理解するのは難しいと思います。 対象サーバにインストールする必要がある Ch
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
意識の低い自動化
ガントチャート上でドラッグ＆ドロップでタスクの並び替えられるようにしてほしい – Customer Feedback for Backlog