スレーブ・サーバのゾーン転送とセキュリティ
規模の大小を問わず、ゾーンサーバは複数台で運用する必要があります。冗長化や負荷分散などさまざまな理由が挙げられますが、何よりドメインを取得してDNSサーバを運用するのであれば、サービスの品質を低下させないという自覚を持つ必要があります。 今回はスレーブ・サーバの運用と、そこで使用されるゾーン転送およびそのセキュリティについて見ていきます。 コラム スレーブ・サーバとセカンダリ・サーバ 本稿では、「マスター・サーバ」のゾーンデータを取得してDNS問い合わせに応答するサーバを「スレーブ・サーバ」と呼んでいます。 資料によっては、同様の意味で「プライマリ・サーバ」「セカンダリ・サーバ」が用いられる場合があり、その際「スレーブ・サーバ」はDNS問い合わせを他サーバへ転送し、自身はDNS再帰検索を行わないサーバを指す場合があります。本連載ではオリジナルとなるゾーンデータを所有するサーバを「マスター・
AWSにおける共有コンテンツ参照方式を検討する（"S3をマウントしたい"から始まった議論の一部始終） - Qiita
1.背景 S3の可用性や耐障害性って魅力的！ ただし、NFSマウントできないので、扱う側がS3のAPIで会話しないといけない。 現行では、複数台あるWebサーバがそれぞれファイルサーバへNFSマウントして共有コンテンツを参照していたんですが、S3だとこの構成がとれない。。。 なんとかならないか？そんな理由で始まった検討経緯を共有します。 2.方式案 思いついたのは、大きく以下の4方式。早速各方式について検討開始しました。 ①：S3コマンドで会話するよう、アプリケーション修正（AWS推奨） ②：何らかの形でS3のバケットをNFSマウントする（S3fsとか） ③：インスタンス側にデータを同期する（S3 syncとか） ④：EC2でファイルサーバを構築する（最終手段） 3.検討の流れ やはり最初は教科書通りにやろうとはしましたが、アプリケーション側の修正が大きいので非現実的でした。 ということで
CentOS 6.5 で LVS (IPVS) を keepalived で冗長化してみる
前回は ipvsadm コマンドを直接使って LVS を冗長化せずに使ってみた。 今回は keepalived を通して LVS を冗長化して使ってみる。 構成は前回と同様、方式は DSR でバランスアルゴリズムは rr を使う。 ただし LVS の IP アドレスは 192.168.33.{11,12} で Web サーバの IP アドレスは 192.168.33.{101,102} に変更している。 LVS 用のホストをセットアップする x2 まずは必要なパッケージをインストールする。 $ sudo yum -y install keepalived ipvsadm インストールできたら keepalived のコンフィグを編集する。 keepalived は LVS をラップする機能がデフォルトで組み込まれているので、コンフィグを変更するだけで動作する。 $ sudo cp /etc
PowerPoint Presentation
1 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. MySQLの高可用性構成 日本オラクル株式会社 山崎 由章 / MySQL Senior Sales Consultant, Asia Pacific and Japan 2 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。 また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことは できません。以下の事項は、マテリアルやコード、機能を提供することをコミットメン ト（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さ い。オラクル製品に関して記載されてい
たった30分でWordPressを冗長化する方法 – (っ´∀｀)っ ゃー | 一撃
突然ですが、WordPressを冗長化したいと思いませんか？1台サーバが落ちてもサービス影響を最小限に、しかもサーバ代以外のお金をかけず冗長化できる方法があるんですよ奥さん。 ■ NW構成 下記の図のようなNW構成で実現可能です。 DBはマルチマスタにせず、マスターDBはServer #1 とし、Server #2、および以降スケールアウトするマシンはすべてSlaveとします。 ■ 障害パターン Server #2 の全体障害および部分障害がおきても、DNSラウンドロビンによりServer #1へアクセスした場合は影響がありません。Server #2のMySQLが落ちていても、Server #1のMySQLが生きている限り影響はありません。Server #1の全体障害およびDB障害の際は、エントリの投稿やコメントをつけたりなどの更新系は止まっても、サイト閲覧には支障ありません。 ■ 用意す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS Black Belt Online Seminar 2016 AWS上でのファイルサーバ構築
MySQL 冗長化モデル
MySQLの冗長化 2013-01-24