10年以上金融機関で働いているインフラエンジニアの落ちないサーバにするための考察です。 ハードウェアの専門家ではないので、正確ではないかもしれません。 今までの経験からの個人的考え方になります。 私たちオンプレ重視のインフラエンジニアは、 クラウドサービスではできない高可用性サーバを導入したり、 複数台構成で１台故障しても問題ない構成のサーバはコスト重視するなど、 システムに最適なサーバを導入しようとしています。 #高可用性サーバを追求する目的 ■アプリに影響を与えないように Active/Standby構成にしていて、インフラ的にはダウンタイムが数秒だとしても、 アプリによっては復旧に時間がかかったり、問題ないことの確認にも時間がかかってしまいます。 また、正しくサーバが落ちればアプリが問題ないとしても、 サーバが中途半端な状態のままになってしまい、なんだかおかしいということもあります。
About 最近cron辛いなーと思っていて、じゃあ使ったことのあるRundeckなのかと思うのですが、冗長性をどう担保しようかなーと悩んでいました。たまたまgithub眺めていたら面白そうなものを見つけたので試してみます！ 解決したいこと 定時にジョブを実行させたい どのサーバで動くかは重要ではなくて、とにかく定期実行させたい（冗長性） disposalなサーバにしたいので、サーバ特有の設定をなるたけ排除したい cronsulとは GitHub - EvanKrall/cronsul: Runs periodic jobs somewhere on a cluster... sorta cron + consul = cronsulということだと思うのですが、その名の通りcronをconsulで制御します。 仕組みとしてはいたって簡単です 1. consulクラスタ上で同じcronを定期
Overview HA-JDBC is a JDBC proxy that provides light-weight, transparent, fault tolerant clustering capability to any underlying JDBC driver. Features Supports any database accessible via JDBC. High fault tolerance - a database cluster can lose a node without failing/corrupting any transactions. Live activation/deactivation allows for maintenance/upgrading of a database node without loss of servic
はじめに ジョブスケジューリングを簡易的な仕組みで構築する場合、まず候補に上がるのはEC2上のLinuxでcronを利用したものだと思います。特別なミドルウェアの追加インストールはいらないし、使い慣れているし、スクリプトと組み合わせればだいたい何でも出来ちゃいますし。しかし単体のEC2上でcronを動かすだけでは、可用性が確保出来ません。AWSにおいてAZ障害まで考慮するのであれば、Multi-AZに冗長化されたシステムを構成し、可用性を確保する必要があります。 で、単純に複数のAZに分散してEC2を構築し、crontabを共有するだけでは、ジョブが二重に実行されてしまいます。アクティブ/スタンバイに動作するような仕組みを考慮しなくてはいけません。 そこで今回は、クラスタ構成がサポートされている最新のcrond(cronie)を使って、Multi-AZに対応した高可用Cronサーバを構築し
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 インターネットにおいて、素晴らしいサービスが沢山生まれてきている一方で、実はそれらを後ろで目立つことなく支えている人達がいます。 はい、それが皆さんご存知の所謂インフラエンジニアと呼ばれる人達です。素晴らしいサービスやアプリケーションがリリースされ、そらを開発したプログラマーが世間からの脚光を浴びている中、インフラエンジニアはその陰に身をひそめ、リリース後からこそ真の地獄が始まる、と言わんばかりに、サーバやネットワークのリソースのグラフを昼夜問わず眺めたり、監視アラートにビクビク怯えながら日々すごしています。 しかし、彼らはシステムを安定稼働させるために、自ら進んで後ろに立ち、常にシステムを最適化するためにはどうしたら良いかを考えてくれている
Redis 2.8 の redis-sentinel によるレプリケーションの自動フェイルオーバーについて、 比較的発生しそうな障害を想定して動作検証してみました。 結論から redis-server の自動再起動を構成している場合は要注意。 daemontools とか。 Master が落ちた後すぐ(例えば数秒)に再起動してきた場合、 再び Master としてレプリケーションに参加します。 よって、Master 再起動の前後でデータに差異があった場合でも、 再起動後のデータをもとに同期される為、データが破壊される可能性があります。 これを回避する為には、Sentinel により sdown/odown として認識されるのを待ってからインスタンスを復帰させるようにします。 復帰が早すぎると、障害(sdown/odown)ではなく再起動(reboot)と認識します。 レプリケーションの再
We are excited to announce the acquisition of Octopai, a leading data lineage and catalog platform that provides data discovery and governance for enterprises to enhance their data-driven decision making. Cloudera’s mission since its inception has been to empower organizations to transform all their data to deliver trusted, valuable, and predictive insights. With AI and […] Read blog post
CDH3から始めてCDH4.1までアップグレードして利用し続けていますが、この過程でNameNodeの構成は変更せずに運用してきました。 当然、CDH4からの公式HA構成に関心はあったのですが、複数の更新を同時に行うと危ないとか、英語マニュアル読むのめんどくせー感からミドルレンジに距離を置いていたところに、もりす先生がトライしてくれて、乗るしかないビッグウェーブ到来。待つべきものは他人の検証とはよく言ったものですなぁ。 タイトルはNameNode構成の切り替え、となっていますが、これから新しくQJM HAで組む人にも役に立つ内容となっていますゆえ、私が血反吐を吐いてまとめた情報を是非ご覧くださいませ。 リンク CDH4.1におけるクォーラムベースジャーナリング Quorum-Journal Design CDH4.1オーバービュー Software Configuration for Qu
Hadoop HDFS の NameNode は長い間単一障害点だったのですが、 CDH 4 から、 NFS 上の edits ログを共有する形でのアクティブ/スタンバイ構成が可能になりました。しかし、フェイルオーバが中途半端になると共有 edits ログが破壊されるとか、 NFS が新しい単一障害点になってしまうとかで、評判が良くなかったようです。 そこで CDH 4.1 からは、 JournalManager という、 edits ログを書き込む専門のデーモンが追加されました。アクティブな NameNode は、 Quorum Journal Manager (QJM) を通じて、共有 edits ログを JournalNode クラスタに書き込めるようになりました。 今回、 QJM ベースの NameNode 冗長化を試すため、 HDFS クラスタを作ってみました。同時に ZooKe
Blog Projects Jason Wilder's Blog Software developer and architect interested in scalability, performance and distributed systems. Fluentd vs Logstash Nov 19, 2013 · 6 minute read · Comments logging realtime fluentd logstash architecture Fluentd and Logstash are two open-source projects that focus on the problem of centralized logging. Both projects address the collection and transport aspect of c
Sadayuki Furuhashi @frsyuki EBSは管理ノードとデータノードで構成される、ハイブリッドなP2Pシステムであるらしい。データは複数のデータノードにレプリケーションされ、その内の一つが "プライマリ" レプリカになっている。データの変更はプライマリレプリカに対してのみ許可される。 2011-05-02 13:21:02 Sadayuki Furuhashi @frsyuki プライマリレプリカは、管理ノードとデータノードにクライアント（=EC2インスタンス）を加えた、3者がネゴシエーションすることで決定される。ポイントは、管理ノードはリージョンに1セット存在する点か。AZに1セット存在するのではない。 2011-05-02 13:24:25 Sadayuki Furuhashi @frsyuki 複数のAZにまたがった管理ノードを置くことで、データを複数AZにまたが
Designing for failure with Amazon Web Services - MNX Solutions
Avoid single points of failure. You can and should assume everything will fail. Start by listing all major points of your architecture, then break it down further, and then maybe one more level. Now review each of these points and consider what would happen if any of these failed. You need to include redundancy or failback plans for each of these areas at a minimum: CloudFrontHave an alternate sol
Chronos is our replacement for cron. It is a distributed and fault-tolerant scheduler which runs on top of Mesos. It’s a framework and supports custom mesos executors as well as the default command executor. Thus by default, Chronos executes SH (on most systems BASH) scripts. Chronos can be used to interact with systems such as Hadoop (incl. EMR), even if the mesos slaves on which execution happen
RabbitMQ 3.1の導入とCluster構成を検証する
RabbitMQ 3.1の導入と冗長化の検証をしたのでメモ。 検証のための構成はフロントのAPサーバー、RabbitMQが動作するキューサーバー、ワーカーそれぞれ二台づつ。キューサーバーが片方死んでも全体が動作し続けられる事、両方がダウンしたとしてもデータは損失しない事が確認できれば良い。要するに単一障害点にならないようにRabbitMQを使いたい。 サーバーの準備 仮想マシン6台はVagrantを使えば一発で用意できる、メモリ16GB積んでてよかった。ホスト名を後でいじるとrabbitmqctlで停止・再起動がうまくいかなくなった。ホスト名周りはEC2で使う時に面倒な事になりそうだ。 各サーバーの /etc/hosts にrabbit1とrabbit2は追加しておく。 RabbitMQ 3.1 のインストール 起動確認 vagrant@rabbit1:~$ sudo rabbitmq-s
2013/05/30に開催した、HDFS HA(High Availability: 高可用性)セミナーの資料です。同じくご登壇頂いた、株式会社サイバーエージェントの上原誠様の資料は↓です。 http://www.slideshare.net/makotouehara39/cl-st-20130530nnhaRead less
大規模なサイトだけでなく、中小規模のサイトにおいても、Webや電子メールなど、増大する一途のサービスや要求に耐え、可用性を高めるため、負荷分散装置を導入するのが一般的になってきています。 しかし、ベンダー各社から負荷分散装置が販売されていますが、どれも高価です。 オープンソースで開発されているL4負荷分散システムとして、Linuxカーネル上に実装されているLVS（Linux Virtual Server）があります。 LVSは、負荷分散専用システムに比べてローコストであり、 Linux上で動作するので、 トラブル時のパケット解析などが比較的容易にできるなどの特徴があります。 LVSの性能はどの位なのでしょうか？ 残念ながら、LVSの性能を評価したものは、インターネット上には見当たりませんでした。そこで今回は、LVSの基本性能について調べるために実験をしてみました。 そもそもL
HAProxyでMySQL HA on Amazon EC2
This document discusses using HAProxy to provide high availability for MySQL databases running on Amazon EC2. It describes setting up a MySQL master-master replication configuration across two EC2 instances with HAProxy load balancing between the databases. HAProxy is configured to monitor the MySQL servers and direct reads to an available master while allowing writes to both masters for redundanc
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
