タグ

gihyoと運用に関するwasaiのブックマーク (6)

  • 第22回 “金融系”インフラエンジニアという業種[その2] | gihyo.jp

    話は少しさかのぼりますが、筆者は社会に出て20年近くが経ちます。 社会人になったころは「バブル期」といわれ、経済が右肩上がりに成長していた時代です。今では信じられないかもしれませんが、就職活動で企業へ訪問すれば、交通費、事代、場合によってはその会社の定める出張費まで出ることがあり、アルバイトをすることに疑問さえ感じる時代でした。そんな中、筆者はある金融系の企業に入社し、その後システム部門へ転属、それから何度となく転職を重ねておりますが、基IT関連のキャリアを歩んでいます。 最初に転職を決意したときはすでに就職氷河期でした。転職活動はそれなり大変でしたが、仕事をする上でどうしても「規模」と「責任感」が両立するシステムに携わりたいと思っていました。当時はネットを使って情報収集というには早すぎる時代であり、なかなか多くの業種を見ることはできなかったのですが、結局のところ金融関連のIT部門に就

    第22回 “金融系”インフラエンジニアという業種[その2] | gihyo.jp
  • 第1回 2011年「あけおめアクセス」の対策と結果 | gihyo.jp

    はじめに はじめまして。(⁠株)ミクシィのシステム部 運用部でアプリ運用を担当している小池知裕です。mixiのシステムの運用/管理業務に従事しています。連載では、3回にわたってmixi.jpでのシステム運用業務の裏側を紹介します。 ミクシィの運用部のシゴト 最初に、(⁠株)ミクシィの運用部という組織について簡単に説明します。運用部には「アプリ運用」「⁠インフラ」「⁠バックオフィス」の3つのグループがあり、それぞれ「ソフトウェア面での運用/管理/改善」「⁠ハードウェア面での運用/管理/改善」「⁠購買/資産管理」の業務を担当しています。 そのほか、同じシステム部には技術部があり、さまざまな研究開発を行う研究開発グループやmixiの大規模障害で有名になった、たんぽぽグループなどがあります。 連載では、筆者が所属するアプリ運用グループで、mixiサービスのソフトウェアをどのように運用/管理

    第1回 2011年「あけおめアクセス」の対策と結果 | gihyo.jp
  • 第5回 Pacemakerを運用してみよう![保守運用編(2)] | gihyo.jp

    ここでは、リソースのmonitor故障検知時の動作について説明します。Pacemakerはリソースのmonitor故障を検知した場合は、故障が発生したサーバにフェイルカウント(フラグ)を立て、リソースのフェイルオーバ処理を実施します。 図1 リソース故障 故障を発生させてみよう では、実際にリソース故障を発生させて、Pacemakerの動きを見てみましょう。今回はリソース故障を擬似的に起こすため、Pacemaker稼働中にhttpdを停止します。 # /etc/init.d/httpd stop httpd停止後crm_monコマンドを実行すると、pm01でhttpdのmonitor故障を検知したため、故障回数と故障内容が表示され、リソースがpm02にフェイルオーバしていることが確認できます。 Online: [ pm01 pm02 ] Resource Group: web vip (o

    第5回 Pacemakerを運用してみよう![保守運用編(2)] | gihyo.jp
  • 第18回 2011年クラウドサービスの適用ドコロ[PART 3] | gihyo.jp

    これまで、クラウドサービスの利用について、障害時などについてのリスクなどについて解説させていただきました。今回は、とうとうサービスを停止することになりました。それにあたって、クラウドサービスを解約するという一連の流れについて記載したいと思います。 事業の決断については大変残念ではありますが、これらクロージングまで含めたクラウドサービスならではの手軽さがあるからこそ「新たなことを気軽に始めることができ、サービスのペイラインをより現実的に見据えつつ、健康的な撤退判断を可能にする」ことができると思います。 停止するのはどこの担当か? 事業会社に置けるクラウドサービスの位置付けという点では、今回のようなサービス停止に関するタスクは「事業側」が行うのか、「⁠インフラ側」が行うのか、会社、事業規模、インスタンスなどの規模にも比例するかもしれませんが、おおよそ「インフラ側」が行うことが多いのではないでし

    第18回 2011年クラウドサービスの適用ドコロ[PART 3] | gihyo.jp
  • 第4回 Pacemakerを運用してみよう![保守運用編(1)] | gihyo.jp

    ※ スプリットブレインなどで相手のサーバを一切認識できなくなったり、Pacemakerが停止しているサーバの状態については、表示されなくなります。 故障回数表示 リソースの故障状態が表示されます。リソースの故障を検知すると、故障が発生したサーバと故障リソースの情報を表示します。故障回数表示に表示される故障情報は、サーバでリソース故障が起きたというフラグにも使用されており、そのフラグのことをフェイルカウントと呼びます。また、migration-threshold が"1"に設定されているため、1回の故障でフェイルオーバが発生していることがわかります。(⁠migration-thresholdについては第2回を参照) 故障内容表示 故障回数表示で表示されたリソースの故障内容として、故障オペレーション(start/monitor/stop⁠)⁠、故障サーバ名、リターンコード(rc)が表示されます

    第4回 Pacemakerを運用してみよう![保守運用編(1)] | gihyo.jp
    wasai
    wasai 2011/04/28
  • 第17回 2011年クラウドサービスの適用ドコロ[PART 2] | gihyo.jp

    3月11日、筆者は少し遅めの昼をとっていました。ちょうどべ終わる頃に、今まで経験したことのないような強さで、何度も、長時間に渡る揺れを体感しました。急いで職場に戻り、情報を収集し事の重大さを認識しました。 この度の東北地方太平洋沖地震により亡くなられた方々のご冥福をお祈り申し上げますとともに、被災されました皆様、またそのご家族の方々に対しまして心よりお見舞い申し上げます。少しでも早い被災地の復旧・復興を祈念いたします。 インフラエンジニアの対応 さて、このような状態になった場合、インフラエンジニアとしてはどのような対応をすべきか考えます。 データセンターの状況 まずは筆者の場合、オフィスは東京都内(23区内⁠)⁠、データセンターは別の東京都内(23区内)にあり、現地に向かいつつも電話でデータセンターの状況(情報)を入手します。これは、データセンターの受付、オペレータが見ることができる範

    第17回 2011年クラウドサービスの適用ドコロ[PART 2] | gihyo.jp
  • 1