Making Apache Airflow Highly Available - Home
In a previous post, we discussed Setting up an Apache Airflow Cluster. In this post we’ll talk about the shortcomings of a typical Apache Airflow Cluster and what can be done to provide a Highly Available Airflow Cluster. A Typical Apache Airflow Cluster In a typical multi-node Airflow cluster you can separate out all the major processes onto separate machines. Here are the main processes: Web Ser
fstaidというHAデーモンを作った - so what
fstaidというHAデーモンを作りました。 github.com HeartbeatとかCorosyncとかPacemakerの代替を考えて作ったソフトウェアです。 なぜ作ったのか？ それほど多くはないんですがたまに「先方の許可するIPアドレスは１つしかないから、フェイルオーバー時にElasticIPを付け替える感じで」という案件がたまにあるんですよ。 そうすると「Corosync/Pacemakerでクラスタ組むか。だるいな…」ということになって、Heartbeat/Corosync/Pacemakerを使いたくない欲が高まった結果、作成されました。 KeepalivedやSerfを使ってクラスタを組むこともできるんですが、どうもやりたいことに対して、オーバーキル感とか明後日の方向感がぬぐえない感じでいました。 話は変わってMHAです。 MHAいいですよね。安定した動作もレプリケーショ
mysqlのHAがらみのトラブルの思い出 - smallpalace's blog
いーつのことーだかー思い出してごーらん、あんなことーそんなことーあーったでしょー。 というわけでこんにちは。smallpalaceです。 ちょっと前にテクニカルセミナー的な機会があって思い出してくれということになり思い出したのでかける範囲で書いときます。 mysqlの運用時のトラブルまとめ。HAがらみのところほか順不同です。 ・高負荷後の「max_connect_errors」がらみでホストによっては拒否されてアクセスできなかったりなど。対策としては、flush hosts;とmax_connect_errors=999999999でエラーカウント無効になるようです。 ・主にクラウド上でI/OスパイクでF/Oしやすい。（I/O共有なのでしょうがないです）ベンダによってはDBだけ物理で提供（納期はかかる）というのもメニューにあったりして人気があるようです。予算が許せばioDriveとかステキ
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
Automating master failover is possible but needs care
I was asked from a few people about my opinion of the Github's recent service outage. As a creator of MHA, I have lots of MySQL failover experiences. Here are my points about failover design. Most of them duplicate with Robert's points. - "Too Many Connections" is not a reason to start automated failover - Do not repeat failover I know some unsuccessful failover stories that "1. failover happens b
Notes on Keepalived and DNS — AntonLindstrom.com
Following the HA trend I created with the last post I though I would write down some notes on high availability DNS with Keepalived. When implementing this I found out that it was poorly documented when using both UDP and TCP traffic. It seems like some people refer to DNS as UDP only. This would disable features like zone transfers and queries over 512 bytes. Keepalived is a load balancer with HA
Data Center High Availability Clusters Design Guide - Data Center High Availability Clusters [Design Zone for Data Centers] - Cisco Systems
Table Of Contents Data Center High Availability Clusters High Availability Clusters Overview HA Clusters Basics HA Clusters in Server Farms Applications Concept of Group LAN Communication Virtual IP Address Public and Private Interface Heartbeats Layer 2 or Layer 3 Connectivity Disk Considerations Shared Disk Quorum Concept Network Design Considerations Routing and Switching Design Importance of t
F5 Networks Japan K.K. - 積極的な取り組みでサイトの安定性と信頼感No.1*を獲得
F5のサイト サポート ポータル F5製品およびサービスに関するセルフサービス ヘルプの記事 DevCentral 弊社主催のコミュニティでつながり、学ぶ My F5 サブスクリプションおよび登録キーの管理 Partner Central F5パートナーのためのリソースおよびサポート ポータル LearnF5 Learn to use F5 products F5へのお問い合わせ F5販売担当部へのお問い合わせ 詳しくは、F5の営業担当社にお問い合わせください F5サポートへのお問い合わせ お近くのサポート担当者にお問い合わせください プロフェッショナルサービスへのお問い合わせ F5ソリューションを最適化するためのサポートを受ける 無料トライアル 複数の環境にわたりアプリケーションの安全性、速度、信頼性を確保するこれらの製品を、無料でお試しください。 F5 Distributed Clou
⚡ Welcome to the ClusterLabs Wiki
ClusterLabs is an informal community hub for open-source, high-availability clustering software. Multiple independent software projects are distributed under the ClusterLabs umbrella. This wiki has how-to's, tips, and other supplemental information for these projects beyond their distributed documentation. Scroll down to Document Hierarchy on any wiki page (including this one) to see related infor
HA構成と復旧作業時間と信頼性 - kazuhoのメモ置き場
２台でHAノードを組んでいて１台が落ちた場合に、何時間以内に再度２台構成に復帰させる必要があるのかなーと思って、ちょっと計算してみた。ノード毎の障害発生の確率が独立であると仮定すると、 $ perl -le 'print exp(log($ARGV[0])/(365*24))**$ARGV[1]' 0.97 1 0.999996522927565のように、サーバの障害発生率が 3%/year で、かつ復旧に１時間かかる場合、復旧中に残存ノードにも障害が発生してサービスが停止する可能性は 0.001% 以下。 $ perl -le 'print exp(log($ARGV[0])/(365*24))**$ARGV[1]' 0.97 24 0.999916553598325２台構成に戻るまで24時間かかる場合だと、約0.01%。 $ perl -le 'print exp(log($ARGV[
最強のMySQL HA化手法 - Semi-Synchronous Replication
MySQL 6.0で搭載される予定の機能の一つに、Semi-Synchronous Replicationというものがある。コイツを使うととんでもなく凄いHA化ができるので、今日はその方法を紹介しよう。 まずはSemi-Synchronous Replicationの機能説明から。そもそもSemi-Synchrounousってナニ？どうして完全な同期でもなく非同期でもなくSemi-Synchronousなの？という疑問をまずは解消したいと思う。さっそく次の図を見て欲しい。 これはSemi-Synchronous Replicationの動作を図で表したものである。図だけではなんだかよく分からないと思うので、以下に各ステップの詳細を説明する。 アプリケーション（クライアント）からトランザクションをCOMMIT要求を出す。 バイナリログを更新する。 ストレージエンジン（テーブル）を更新する。
Zero-Downtime Restarts with HAProxy - igvita.com
By Ilya Grigorik on December 02, 2008 Putting up a maintenance page while you are doing an update and restarting your application servers is good practice, but it definitely hurts the user experience. This, in turn, translates to less frequent releases and frustration for both the developer and the users (release often, release early!). To address this, the Rails community has come up with a coupl
Heartbeatの特徴とユニークな機能
はじめに 今回から数回にわたって、オープンソースのHA（高可用性）クラスタ構築ソフトウェア「Heartbeat」を題材にして、「クラスタリングとは何か？」というところから、Heartbeat自体の解説、Heartbeatを用いてのHAクラスタの構築、モニタリングなどについて解説していきたいと思います。皆さんお付き合いのほど、よろしくお願いいたします。 クラスタリングって何だろう？ まず、「クラスタリングとは何か」というところから始めてみましょう。この質問に簡単に答えてしまうと「あるミッションに対し、複数のコンピュータ（群＝クラスタ）をもって対処する構成」だといえます。ですが、状況に応じてさまざまなミッションのタイプがありますから、それに対するクラスタリング（構成）も自然と変わってきます。 なお、Linuxでのクラスタリングの歴史は意外と古くまでさかのぼることができます。約十年前の雑誌ですで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
第4回Linux-HA勉強会資料 Pacemakerの紹介
株式会社TAP
株式会社TAP
https://backhand.org/wackamole/
ldirectordで、LVS（Linux Virtual Server）による負荷分散システムの構築