序章
この記事の最初の部分では、VPSでデータをバックアップするためのさまざまなソリューションを検討しました。
この記事では、冗長性の概念について説明します。 冗長データはバックアップではありませんが、データにアクセスするための主要な方法が使用できなくなった場合にフェイルオーバーを提供できます。
システムにレプリケーションを実装する方法は、主に、データの使用方法、防御する障害、および訪問者がサーバーインスタンスと対話する方法によって異なります。
RAIDの冗長性
おそらく最も一般的なタイプのレプリケーションはRAIDです。 RAIDは、独立したディスクの冗長アレイの略です。 これは、ほとんどの構成で、ディスクが何らかの方法で相互にミラーリングすることを意味します。
最も基本的な冗長RAIDの実装は、RAID1アレイです。 このタイプのアレイは、あるディスクを別のディスクにミラーリングします。 これは、一方のディスクに障害が発生した場合でも、もう一方のディスクを使用してデータを提供および書き込みできることを意味します。 このタイプの配列は、システムがいずれかのデータ位置から読み取ることができるため、読み取りを高速化します。
この例は、RAIDおよび一般的な冗長セットアップが適切なバックアップではない理由の良い例でもあります。 ファイルを削除すると、そのファイルは完全に削除されます。 すべての変更はすぐに両方のディスクに適用されます。
RAIDレプリケーションは低レベルで実装されるため、DigitalOceanVPSでのRAID実装を制御することはできません。
ブロックレベルの冗長性
冗長性を提供する別の方法は、ブロック構造全体をミラーリングすることです。 DRBD 、または分散複製ブロックデバイスは、ブロックデバイス間で冗長性を実現する方法です。
これは、ミラー化されたRAIDアレイに似ているように見えるかもしれませんが、ある意味ではそうです。 違いは、レプリケーションが行われる場所にあります。 RAIDを使用すると、冗長性はアプリケーションレベルより下で発生します。 RAIDカードまたはRAIDソフトウェアは、物理ストレージデバイスを管理し、アプリケーションに単一の見かけのデバイスを提示します。
一方、DRBDはまったく異なる方法で構成されます。 DRBDセットアップでは、各ハードウェアスタックが完全にミラーリングされます。 アプリケーションインターフェイスもミラーリングされます。 これは、処理するデータのコピーを備えた完全に別個のマシンがあるため、アプリケーションの障害に対処できることを意味します。 最初のサーバーに電源障害が発生した場合でも、2番目のサーバーは効果的に動作します。
SQLレプリケーション
重要なデータがSQLデータベース（MySQL、MariaDB、PostgreSQLなど）に保存されている場合は、いくつかの組み込みのレプリケーション機能を利用できます。 これらは、メインサーバーがダウンした場合のフェイルオーバーシステムを提供するために使用できます。
マスタースレーブレプリケーション
最も基本的な種類のSQLレプリケーションは、マスタースレーブ構成です。 このシナリオでは、「マスター」サーバーと呼ばれるメインデータベースサーバーがあります。 このサーバーは、すべての書き込みと更新を実行する責任があります。 このサーバーからのデータは、「スレーブ」サーバーに継続的にコピーされます。 このサーバーは、読み取りはできますが、書き込みはできません。
この設定により、読み取りを複数のマシンに分散でき、アプリケーションのパフォーマンスを劇的に向上させることができます。
このパフォーマンスの向上は利点ですが、マスタースレーブレプリケーションを設定する主な理由の1つは、フェイルオーバーを処理するためです。 マスターサーバーが使用できなくなった場合でも、スレーブサーバーから読み取ることができます。 さらに、マスターが長期間オフラインになった場合に、スレーブをマスターサーバーに変換することができます。
実際、マスタースレーブレプリケーションは、冗長性とバックアップがどのように相互に補完できるかを確認し始める1つの領域です。 マスタースレーブ構成では、マスターからスレーブにデータを複製できます。 次に、レプリケーションを一時的に無効にして、スレーブ上の情報の一貫した状態を維持できます。 ここから、適切なバックアップメカニズムを使用してデータベースをバックアップできます。
MySQLマスタースレーブレプリケーションの構成方法の詳細については、ここをクリックしてください。 PostgreSQL を使用してマスター/スレーブレプリケーションを実行する方法については、このリンクをたどってください。
マスター-マスターレプリケーション
レプリケーションの2番目の形式は、マスター-マスターレプリケーションと呼ばれます。 この構成により、両方のサーバーに「マスター」機能を持たせることができます。 これは、各サーバーが書き込みと更新を受け入れ、変更を反対側のサーバーに転送できることを意味します。 この構成は、マスタースレーブセットアップの利点を継承しますが、負荷分散メカニズムによって書き込みが適切に分散される場合は、書き込みパフォーマンスが向上するという利点もあります。
これは、一方のサーバーがダウンした場合でも、もう一方のサーバーは稼働していて、要求を受け入れる準備ができていることも意味します。 構成はより複雑ですが、問題が発生した場合のフェイルオーバーは、スレーブデータベースをマスターに変換する必要がないため、マスタースレーブの冗長性よりも複雑ではありません。
マスターサーバーの1つをオフラインにする場合は、この構成をバックアップメカニズムと組み合わせることもできます。 バックアップが正しく機能するためには静的データベースを維持する必要があるため、バックアップが完了するまでデータが変更または書き込まれないようにする必要があります。
マスター-マスターレプリケーションの構成方法の詳細については、ここをクリックしてください。
冗長性の代替手段としての配布
分散システムは、従来の冗長セットアップの多くの利点を提供します。
上記のミラー化されたRAIDレベル（RAID 1）についてはすでに説明しました。 もう1つの一般的なRAIDレベルはRAID5です。 このRAIDは、複数のドライブにデータを分散し、各ドライブにデータのパリティを書き込みます。 これは、単一のドライブが停止した場合に、他のドライブのパリティ情報を組み合わせることで、あらゆる種類のトランザクションを「再構築」できることを意味します。
これにより、ディスク間でデータを分散する別の方法が提供され、単一のディスク障害も処理できます。
分散システムは、ハードウェアベースである必要はありません。 分散データを主要な機能として設計されたデータベースやその他のソフトウェアソリューションもかなりあります。
この例は、分散データベースであるRiakです。 Riakノードはすべて同じです。 異なる部分の間にマスター/スレーブの関係はありません。 データベースに格納されているオブジェクトは複製されるため、その点で従来の冗長性があります。
ただし、各ノードがデータベース全体を保持しているわけではありません。 代わりに、データはノード間で均等に分散されます。 複製されるオブジェクトは、ハードウェア障害が発生した場合の可用性を考慮して、異なるノードに配置されます。
データベースに実装されたこの概念のもう1つの優れた例は、Cassandraです。 Riakと同じ原則に基づいていますが、実装方法が異なります。
結論
ご覧のとおり、冗長性には多くのオプションがあり、それぞれに長所と短所があります。 これは主に、予測しようとしている問題と、システムのどの部分で障害を許容できないと見なすかによって異なります。 ご想像のとおり、これらの手法のいくつかを組み合わせると、常により包括的なセーフティネットが得られます。
また、この時点で、冗長セットアップがバックアップの代わりにはならないこともわかります。 冗長システムが常に動作し、変更を常にミラーリングする必要があるため、構成のすべてのポイントからデータを簡単に破棄できます。
データの整合性とアクセスが不可欠なアプリケーションの場合、冗長性とバックアップの両方が非常に重要です。 適切に実装することで、ユーザーは常に製品を利用でき、重要なデータが失われることはありません。
