今こそ真剣に考える「災害対策システム」──クラウドと「DRBD Proxy」ですぐ構築する方法：DRBDの仕組みを学ぶ（7）（1/3 ページ） 「災害対策」を行っていますでしょうか。必要とは理解しつつも、高額で手をつけられない事情も多くあるでしょう。今回は、中堅中小企業でもソフトウェアのみですぐ実行できる、災害対策システムを構築する方法を解説します。 連載バックナンバー 東日本大震災から、もう5年が経過します。 自然災害の発生は予測できません。しかし、「障害の発生を見越した準備」はできます。サービスを止めない、とはどういうことか。仮にシステムダウンがあっても業務に影響を与える「前」に復旧するシステムをどう構築するか。東日本大震災を機に、このような「事業継続計画（BCP）」と「災害復旧対策システム（DR）」の重要性が広く認識されました。 しかし現在はどうでしょう。皆さんはその重要性を理解して
連載バックナンバー 前回まで、DRBD（Distributed Replicated Block Device）の基礎と概要、よく使われるDRBDの例である「高可用性システムの場合」と「災害対策システムの場合」の運用イメージを解説しました。しかし、高可用性システムとなると、自分の担当ではなかったり、規模が大きすぎて運用イメージがなかったりする人がいたかもしれません。 では、「Sambaファイルサーバーを冗長化する」ならばいかがでしょう。 今回は、こういったより身近な運用シーンからまずは「即導入」し、今後、自然災害などで被害を受けたシステムを復旧・修復する「DR（ディザスタリカバリ）」対策まで含めてイメージできるよう、OSの準備からDRBDのインストール手順、設定ファイルの記述方法と解説、構築や運用テクニックまで、順を追って説明します。 今回の構成イメージを図1に示します。二台のSambaサ
「高可用性システム」で、DRBDをどう活用するか：DRBDの仕組みを学ぶ（2）（1/3 ページ） 連載バックナンバー 連載第一回目の前回は、「DRBD（Distributed Replicated Block Device）」の基本的な機能と動作について解説しました。 DRBDの仕組みを学ぶ（1）：DRBD（Distributed Replicated Block Device）とは何か 今回は、より実践を踏まえた話に入ります。DRBDが最も使われている「高可用性システム」での活用例を解説します。 高可用性システムにおけるDRBDの活用例 前回、サーバー2台の冗長構成でサービスを継続させるために、DRBDがどのような動きをするのか、この基本を説明しました。プライマリ機で障害が発生したら、プライマリ機とセカンダリ機を切り替えて、これまでのセカンダリ機をプライマリ機に変更します。そして、データ
前置き CentOS+Pacemaker+Corosync+DRBDで以下の図のようなHA構成を作り、そこにOracleデータベースを実装しました。 HA構成をOSSで作っておいてわざわざOracleを使う人は少ないのか、あまり実装例が無いようなので、拙い内容ではありますが書いてみました。 システム構成 ノードA ホスト名:OraSv1 eth0:192.168.10.101 eth1:192.168.1.101 ノードB ホスト名:OraSv2 eth0:192.168.10.102 eth1:192.168.1.102 サービス用LAN 192.168.10.0/24 仮想IP:192.168.10.100 死活監視用LAN 192.168.1.0/24 使ったもの CentOS 6.6 drbd 8.4 pacemaker 1.1.12 corosync 2.3.4 Oracle 1
2012/2/19に実施されたFusion-io社主催の「ioDriveを用いたDRBDによる高信頼性Oracleの構築勉強会」で使用したスライドです。 口頭で話した部分が多いのですが参考まで。Read less
[PR] なぜ今さら、NFSサーバーのようなレガシーなものを？ とお考えの方も多いことと思われます。私の考えでは、レガシーなものが今までどおり使えることこそが、パブリッククラウド利用促進の原動力です。リレーショナル・データベースが不要になるでしょうか。ファイルサーバーはどうでしょうか。仕様が多少変わりながらも、末永く利用されるものだと思われます。 ネットワーク 24×365運営、商用利用を視野に入れた場合、冗長化構成が必須となります。SoftLayerでは、既存の技術がそのまま利用可能です。VLAN上のL2通信がブロックされていません。VLANにPortable IP Addressを割り当てれば、VIPも利用可能となります。SoftLayerが標準で用意しているルーター経由でルーティングしなくてもよいということであれば、自由にプライベートIPアドレスを割り振ることもできます。 物理サーバ
OSSの商用利用に安心を LINBITクラスタスタック・サポートは商用でOSSを安心してご利用いただく為のサポートサービスです。LINBIT社のOSSであるDRBD / Pacemaker / Corosync に日本語サポートとホットフィックスを提供します。 カタログダウンロード LINBITクラスタスタック・サポートは、LINBIT社のOSSであるDRBD / Pacemaker / Corosync に日本語サポートとホットフィックスを提供するサポートサービスです。 システム障害時のHAに加え、遠隔地へのレプリケーションを実現するDR（Disaster Recovery）、分散ブロックストレージを提供するSDS（Software Defined Storage）という3つの提供形態をサポートしています。
MySQLをDRBDと組み合わせて検証をしていた際にタイムラインに流れていた、DRBDの苦労話をまとめました。 ちょうどファーストサーバさんで大規模障害があった時期ですので、そちらに関する内容も一部含まれています。
今さらですが、Amazon RDSのマルチAZデプロイメントについて調べていました。マルチAZデプロイメントとは、独立した電源、空調、ネットワーク、セキュリティを備えた物理的に異なるロケーションに対して同期レプリケーションを行うことで、データベースの耐障害性を高める機能です。AZはAvailability Zoneの略です。 異なるロケーションに対する同期レプリケーションと聞くと、性能が出ないのではないかという懸念がどうしても出てきます。そこで、どの程度性能が落ちるものなのか検証を行いました。なお、すでに実際のAmazon RDSを利用して検証を行った方がいらっしゃいましたので、今回は手元の環境を利用して、ネットワーク遅延やMySQLパラメータと性能との関連性を確認していきたいと思います。 Amazon RDS MYSQL Performance Benchmarking - Cloud
きわめて多数の会員を管理するデータベースサーバなど、きわめて高速なディスクI/O、しかもランダムアクセスが必要なアプリケーションがあります。通常のハードディスク(HDD)では読み込み、書き込み性能ともに限界があるため、分散データベース構成で対応しているケースがあります。このような分野などを狙った製品にFusion-io社の超高速半導体ストレージ製品のioDriveがあります。IOPSやレイテンシはたしかにケタ違いです。 しかし、高速に頻繁にデータを書き換えるということは、ストレージ自体やサーバ筐体が故障したときにダメージも大きくなることを意味します。ホットバックアップしてあっても、リストアするとデータ内容はバックアップ時点の状態に戻ってしまいます。やはりここは、DRBDのようなリアルタイムの筐体間レプリケーションの出番です。 しかし、ioDriveの読み書き性能は数百メガバイト/秒のオーダ
fols.net is not accessible... Sorry. I do not know why this site is not working. If you know Administrator of this site, please contact directly. You may be able to see it in Google cache. For administrator ... MyDNS.JP did not received IP address from you over One week. Please check your notify system. If you restart notification of IP address, MyDNS.JP will apply your IP address to DNS informati
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
