ダウンタイムの最小化: 自動フェイルオーバーでのマルチ AZ - Redis 用 Amazon ElastiCache
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Valkey および Redis OSS でマルチ AZ を使用して ElastiCache のダウンタイムを最小限に抑える ElastiCache for Valkey および Redis OSS がプライマリノードを置き換える必要があるインスタンスは多数あります。これには、特定のタイプの計画されたメンテナンスや、プライマリノードまたはアベイラビリティーゾーンの障害というまれなイベントが含まれます。 この置き換えにより、クラスターのダウンタイムが発生しますが、マルチ AZ が有効になっている場合、ダウンタイムは最小限に抑えられます。プライマリノードのロールは、いずれかのリードレプリカに自動的にフェイルオーバーされます。ElastiCache ではこれを透過的に処理
2020年6月3日のアップデートでDirect Connectのフェイルオーバーテストが可能になりました。 AWSとオンプレミスの接続をする時にはDirect Connectが用いられますが、障害対策として、2本の接続を利用することもよくあります。 1本で障害が起きても、もう1本あるから大丈夫。。。大丈夫なはず。。。テストしたい。。。 それが実現できるようになりました。 AWS Direct Connect enables Failover Testing AWS Direct Connect Failover Test やってみた たまたま手元にDirect Connectの冗長構成があったので、やってみました。 準備 効果測定のためにEC2インスタンスから、Direct Connect経由のサーバに対し、pingを打ち続けます。 ubuntu@ip-10-0-0-10:~$ ping
営業部 佐竹です。 本日は、2021年9月2日 の 午前7時30分から午後1時42分までの間に発生していた「東京リージョンにおけるダイレクトコネクト（専用線：以下 DX と記載）障害に関する記事となります。 はじめに 影響範囲について 一時的な対応策 DX をダウンさせる 1-1. CGW で NIC を Shutdown する 1-2. 物理線を抜く 1-3. DX フェイルオーバーテストの実行 2021年10月5日 追記 BGP 設定で対応する 2-1. 広報経路を更新する その他の手法 参考情報 Personal Health Dashboard の履歴1 [4:00 PM PDT] [4:45 PM PDT] [6:49 PM PDT] [6:49 PM PDT] [9:56 PM PDT] Personal Health Dashboard の履歴2 [05:39 PM PDT]
しばたです。 例えばですが、システム開発においてRDSを利用するにあたり開発期間中はSingle-AZ構成にしてランニングコストを節約、受入テストや本番稼働の際にMulti-AZにして可用性を確保するといった運用は良くあるかと思います。 本記事ではこういった場合のためにRDSのMulti-AZ構成を切り替える手順について解説します。 検証環境 本記事では私が慣れているRDS for Oracle(Oracle 19c SE2, db.m5.large)で説明します。 他のRDBMSでも基本同様の手順となります。 また、RDSを構成するネットワーク設定およびRDSインスタンス自体は構築済みの前提です。 1. Multi-AZ構成からSingle-AZ構成に変更する まずはMulit-AZ構成の環境をSingle-AZ構成にする方法を紹介します。 最初にマネジメントコンソールからRDSサービス
![[小ネタ] RDSのMulti-AZ構成を切り替える手順 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/3b6eedbd02faf420a06aa05ca78d478cfa7b4cca/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Famazon-rds.png)
CloudFront オリジンフェイルオーバーを使用して高可用性を最適化する - Amazon CloudFront
高可用性が必要なシナリオでは、オリジンフェイルオーバーを使用するように CloudFront を設定できます。開始するには、プライマリとセカンダリの 2 つのオリジンを持つオリジングループを作成します。プライマリオリジンが使用できない場合、または障害を示す特定の HTTP レスポンスステータスコードを返す場合、CloudFront は自動的にセカンダリオリジンに切り替わります。 オリジンフェイルオーバーを設定するには、少なくとも 2 つのオリジンを持つディストリビューションが必要です。次に、1 つをプライマリとして設定した 2 つのオリジンを含むディストリビューションのオリジングループを作成します。最後に、オリジングループを使用するようにキャッシュ動作を作成または更新します。 オリジングループを設定して特定のオリジンフェイルオーバーオプションを設定する手順については、「オリジングループを作
[アップデート] CloudFrontのみでオリジンフェイルオーバーが出来るようになりました！ | DevelopersIO
従来は Route 53 の DNS フェイルオーバーと組み合わせなどありましたが、今回のアップデートで CloudFront のみでフェイルオーバーが実装できるようになりました！ 昨日のアップデートですが、CloudFront の機能だけで、オリジンのフェイルオーバが実装できるようになりました。 Amazon CloudFront announces support for Origin Failover 従来は Route 53 の DNS フェイルオーバー を利用して実装されていたかと思います。CloudFront 側でフェイルオーバのコントロールが出来るようになったことで、より管理がシンプルになりそうですね！また、サイト単位でのフェイルオーバではなく、動作としてはオブジェクト単位でのフェイルオーバになります。 では、さっそく試していきましょう！ 試してみた 今回はオリジンアクセスア
![[アップデート] CloudFrontのみでオリジンフェイルオーバーが出来るようになりました！ | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/9a7d6ae9f85c16e05f342f3fbedf931e89d9434a/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2018%2F11%2Feyecatch_amazon-cloudfront_1200x630.jpeg)
以前投稿したbgwokerで超簡易クラスタ管理を進化させたpg_keeperについて投稿。 コンセプト このツールのコンセプトは**「PostgreSQLの自動フェイルオーバーを簡単に設定する」です。 Pacemaker/corosyncやrepmgrを使えばより細かく、柔軟に設定することが出来ますが、その一方設定が面倒だったり、多くのケースではそこまで柔軟な設定は必要ないと思ったので、「マスタ、スレーブ2台構成でもっと簡単に可用性を向上させたい」**と思い作りました。 監視プロセスはPostgreSQLのプロセスの一つとして動作するので、高機能なクラスタリングミドルウェアによくある監視プロセス自体の起動・停止・監視等の作業は発生しません。 ただし、pg_keeperが対応しているのはマスタ1台、スタンバイ1台で同期レプリケーションを使用した場合のみです。 スタンバイを2台以上使用するケー
redis_failover provides a full automatic master/slave failover solution for Ruby. Redis does not currently provide an automatic failover capability when configured for master/slave replication. When the master node dies, a new master must be manually brought online and assigned as the slave's new master. This manual switch-over is not desirable in high traffic sites where Redis is a critical part
Redis は基本的にシングルスレッド、イベントドリブンモデルなので、時間のかかるLua スクリプトを実行したらどうなるかというのは想像に難くないのですが確認してみました。 Redis は 2.6.14 です。 redis-cli eval 'while true do print("hello") end' 0な感じのを実行します。 実行中に、別クライアントから GET, INFO, PING すると全てブロックされて結果が返ってきません。 redis.conf で lua-time-limit 5000 と設定している場合は、5秒後に redis-server のログに [18068] 22 Jul 13:51:23.798 # Lua slow script detected: still in execution after 5000 milliseconds. You can t
遭遇した状況 今回は中でも ElastiCache プライマリクラスターのみで障害が発生した場合 の話しです。 ドキュメントにもあるように、マルチAZ 環境での自動フェイルオーバーでの今回の状況においては 書き込みは、昇格プロセスが完了するとすぐに (通常は数分) 再開できます。ElastiCache が昇格したレプリカの DNS を反映させるため、書き込みのためのエンドポイントを変更する必要はありません。 となっています。 ポイントは、「DNS を反映させるため、書き込みのためのエンドポイントを変更する必要がありません」というところです。 発生した課題 自動フェイルオーバーが発生した際に、運用している Rails アプリから上記のエラーが止まらないと言う状況になりました。 最終的には、Web アプリ、ワーカーアプリともに、再起動することで状況は改善しました。 このエラーメッセージから分か
DNSフロントエンドサービスのRoute53でフェイルオーバー機能が使えるようになったぞ Route53に参照先へのHTTP/TCPヘルスチェックがついて、ダウンしたとき用のレコードを登録できるぞ S3 で静的ページ作ってバックアップサイトにしとくといいかもね。ヘルスチェックの詳細は Route 53 Developer Guide をチェケラッ cf: http://aws.typepad.com/aws_japan/2013/02/create-a-backup-website-using-route-53-dns-failover-and-s3-website-hosting-.html コメント ヘルスチェックもついてるので EC2 インスタンスを2台作って冗長性を持たせるというのにも使えるだろうけど、それなら ELB を使えば良いので、解説にもある通り S3 で静的ページが現実的
日本時間 2014/11/27 の AM9時〜AM11時頃まで、全世界的に Amazon CloudFront に障害がありました。 CDNとして CloudFront を利用しつつ、障害時にはフェイルオーバーする方法をまとめました。 S3 CloudFrontのOriginがS3でない場合は、この項の設定は関係ありません。 CloudFrontのOriginとしてS3を使う場合、以下のようにします。 file.example.jp のような、使いたいドメイン名で S3バケット を作る Static Website Hosting を有効にしておく ドメイン名のバケットで Static Website Hosting が有効になっていないと、後述の Route53 の Alias Target に設定できません。 Health Check Route53 の Health Checks を
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "スイッチオーバー" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL (2022年12月) スイッチオーバー（英: Switchover）とは、あるコンピュータ・サーバ/システム/ネットワークから冗長あるいは待機のサーバ/システム/ネットワークへと、手動で切り替えることを指す[1]。通常、何らかの異常が発生したときに行う。フェイルオーバーとは異なり、人手による介入が発生する。 障害発生時以外にも、パッチをインストールする場合、新しいバージョンにアップデートする場合などの保守作業時に行われる。また、システムが複雑すぎて自動的なフェイルオーバー
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "フェイルオーバー" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL (2017年12月) フェイルオーバー（英語: failover）は、現用系コンピュータサーバ/システム/ネットワークで異常事態が発生したとき、自動的に冗長な待機系コンピュータサーバ/システム/ネットワークに切り換える機能を意味する。これに対して、何らかの異常を察知して、人間が手動で切り替えを行うことをスイッチオーバーという。 システム設計において、高い可用性と信頼性が要求される場合、フェイルオーバー機能を組み込むのが一般的である。場合によっては、自動的なフェイルオーバー
こんにちは、宇津井です。 弊社ではゲソてんというゲームプラットフォームを運営しております。ゲソてんではサービスリリース当初から主にキャッシュ的な役割でRedisを導入していました。つい先日の事ですが訳あってRedis 2.6からサポートされたRedis Sentinelを採用しました。今回は、採用に至った経緯をご紹介します。 簡単なシステム構成 パフォーマンスは良いし、Memcachedには無い便利な機能を提供するRedisですが約一年間運用していくつかの問題が出てきました。 Redisサーバーが突然高負荷に陥るするとWebサーバーも高負荷に陥るRedisのReplicationは張ってるけどアプリケーション側でRedis Slaveへフェイルオーバーしない（MySQLを直接参照する）Redis落ちると恐らくMySQLサーバーが耐えられない（落ちた事無いけど）という事で対策を行ってきました
4月11日から米サンタクララで行われた「MySQL Conference & Expo 2011」。このイベントでDeNAの松信嘉範（まつのぶよしのり）氏が、同社の大規模なMySQLの運用を支えている技術とツールについてのセッション「Automated, Non-Stop MySQL Operations and Failover」を行いました。 プレゼンテーションの中で、社内で利用しているフェイルオーバーの自動化ツールをオープンソース化することにも触れています（英語のドキュメントも作成中とのこと）。 MySQLの大規模運用における自動フェイルオーバーは、特にクラウドでのMySQLの利用が増えるにつれてニーズが高まる分野と思われます。セッションのスライドが公開されていますので、そのポイントを紹介していきます。 自動化されたノンストップなMySQLの運用 ソーシャルゲームでは高可用性が強く求
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
