謎解きされた高可用性アーキテクチャ
高可用性アーキテクチャとは何ですか?
高可用性アーキテクチャとは、ピーク時の負荷に関係なく、連携して最適なパフォーマンスを維持するさまざまなコンポーネント、モジュール、またはサービスが存在する場合です。
最も純粋な意味で、このシステムは、企業が一定期間にわたって失敗することなく継続的に作業することを可能にします。多くの企業は、1分でもダウンタイムを許容できません。データが多くのビジネスの生命線であることを考えると、ほんの短い期間のダウンタイムでさえ、信じられないほどコストがかかる可能性があります。
特定の実際のシナリオでは、高可用性のために構築されたデータベースに依存する場合があります。患者が救急治療室に到着すると、医療専門家は自分の医療記録に即座にアクセスして、どの治療法の決定が最善かを理解する必要があります。この情報へのアクセスが遅れると、壊滅的な影響を与える可能性があります。
注:高可用性は、多くの場合、ユーザーがサービスを利用できる時間の割合で測定されます。 Microsoft Network Developer Glossaryによると、サーバーが「高可用性」と見なされるには、99.999%のネットワーク稼働時間を達成する必要があります。
高可用性クラスターとは何ですか?
高可用性クラスターは、ダウンタイムを防ぐために単一のシステムとしてマージされるホストのグループです。高可用性クラスター内の1つのサーバーがダウンした場合、障害が検出されるとすぐに、ミッションクリティカルなアプリが別のサーバーに転送されます。
障害の影響を受けないシステムはありません。高可用性クラスターにより、避けられない障害に関係なく、最適なパフォーマンスレベルが維持されます。その結果、これらは最もミッションクリティカルなアプリケーション、Webサイト、およびトランザクション処理システムに使用される傾向があります。
高可用性クラスタリングはどのように機能しますか?
高可用性クラスターは、すでに統合されている複数のシステムを利用するため、障害によって1つのシステムに障害が発生した場合、別のシステムを効率的に活用して、使用されているサービスまたはアプリケーションの継続性を維持できます。
高可用性負荷分散クラスターは、システム障害の防止に重要な役割を果たします。ロードバランサーを配置すると、基本的に、同じWebサイトまたはアプリケーションユーザーにサービスを提供しているさまざまなWebノードにトラフィックが分散されます。これにより、1台のサーバーへの負荷が軽減され、トラフィックを正常なサーバーにのみ送信できるようにしながら、各クラスターがより最適に機能できるようになります。
高可用性クラスターの概念
アクティブ-パッシブクラスター
アクティブ/パッシブクラスターは、少なくとも2つのノードで構成されます。名前が示すように、すべてのノードがアクティブになるわけではありません。 1つのノードがアクティブな場合、2番目のノードはスタンバイで読み取り専用です。パッシブサーバーはバックアップとして機能し、アクティブサーバーが機能しなくなった場合に利用されます。
アクティブ-アクティブクラスター
このタイプのクラスターは通常、同じサービスを同時に実行する少なくとも2つのノードを使用します。アクティブ-アクティブクラスターでは、両方のノードがプライマリノードとして機能します。つまり、読み取りまたは書き込みのいずれかを受け入れることができます。一方のノードに障害が発生した場合、サービスの継続性を確保するために、ユーザーは自動的にもう一方のノードに接続されます。最初のノードが置き換えられると、ユーザーは2つの元のノードに分割されます。
アクティブ/アクティブクラスターの包括的な利点は、ノードとネットワークのバランスをとることができることです。サーバー障害インスタンスが検出されると、ロードバランサーは、すぐに利用できるサーバーにユーザーリクエストを送信し、ノードネットワークアクティビティを分析します。次に、ロードバランサーは、トラフィックを処理できるノードにトラフィックをプッシュし、より高いレベルのフォールトトレランスを可能にします
この戦略は、ラウンドロビンモデルと同様の循環プロセスに従います。これにより、ユーザーは利用可能なノード全体にランダムに分散されます。または、逆に、パーセンテージに基づいて1つのノードが別のノードよりも優先される重み付けスキームに従う場合があります。
シェアードナッシングvs.シェアードディスククラスター
分散コンピューティングで従う一般的なルールは、あらゆるコストで単一障害点を回避することです。これには、フルサービスがダウンした場合に単一の要因が中断されることなく、リソースをアクティブに複製または交換可能にする必要があります。
1つのデータベースから電力を供給される実行中のノードが50個あると想像してみてください。 1つのノードに障害が発生しても、実行中のノードの数に関係なく、他のノードの永続状態に影響を与えることはありません。
しかし、データベースに障害が発生した場合、クラスター全体がダウンし、データベースが単一障害点になりますか?これは、共有ディスククラスターと呼ばれます。
一方、各ノードがデータベースを維持している場合、ノードの障害がクラスター全体に影響を与えることはありません。これは、シェアードナッシングクラスターと呼ばれます。
注: 高可用性クラスタリングテクノロジーについて詳しく知りたい場合は、このウェビナーをご覧ください。ソフトウェア業界で20年以上の経験を持つGeorgeCarbonnelは、RedisEnterpriseを使用したクラスタリングテクノロジーが高パフォーマンスと高可用性をどのように実現するかについて知る必要があるすべてを解き明かします。
高可用性アーキテクチャの要件
耐久性と高可用性を最大化するために必要なさまざまな要件があります。これらには以下が含まれます:
負荷分散
負荷分散は、可用性の高いアーキテクチャにとって非常に重要です。その主な機能は、バックエンドサーバー間でトラフィックを分散して、データをより効率的に送信し、サーバーの過負荷を防ぐことです。負荷分散システムの前提条件は、ノードに障害が発生したときに実行する必要があるフェイルオーバープロセスを特定することです。
データのスケーラビリティ
データベースまたはディスクストレージユニットを拡張する機能は、すべての高可用性アーキテクチャで考慮に入れる必要があります。スケーラビリティを実現するために選択できるソリューションは2つあります。
- アーキテクチャのメインデータベースを利用し、レプリケーションまたはパーティショニングを使用して高可用性を実現します。または
- 個々のアプリケーションインスタンスが独自のデータストレージを維持できるようにする
地理的多様性
私たちはペースの速いデジタル世界に住んでおり、可用性の高いクラスターを世界中に分散できることが義務付けられています。そうすることで、自然災害が1つの場所を襲った場合でも、その影響によってサービスの提供が妨げられることはありません。
バックアップとリカバリ(ディザスタリカバリ)
すべての一貫性のために、高可用性アーキテクチャは、サービスを中断させる可能性のあるある種の誤動作の影響を常に受けやすくなります。したがって、サービスがダウンした場合、企業はシステム全体を可能な限り迅速に再稼働させるために利用可能なリカバリ戦略を用意する必要があります。
これは、ディザスタリカバリと呼ばれることがよくあります。これは、破壊的なイベントが発生した場合にサービスを完全な機能に戻すように設計された一連のポリシーと手順です。
高可用性を測定する方法
高可用性は、多くの場合、ユーザーがサービスを利用できる時間の割合で測定されます。これは、合計稼働時間をシステム期間で除算し、次に100を掛けてパーセンテージを取得することによって行われます。 Microsoft Network Developer Glossaryによると、サーバーが「高可用性」と見なされるには、99.999%のネットワーク稼働時間を達成する必要があります。
多くの場合、可用性のパーセンテージは、桁の9の数と呼ばれます。したがって、フォーナインは99.99%になります。
注: 99.99%の可用性は、業界標準と見なされます。
高可用性のベストプラクティス
チェックする必要のあるコンポーネントの数から障害が発生したサーバーの交換まで、高可用性を最大化するために実行できるいくつかの手順があります。高可用性を実現するために使用できるいくつかのプラクティスを次に示します。
地理的な冗長性を実現する
地理的冗長性は、サービスの障害につながる可能性のある自然災害の発生に対する重要な防御線です。この方法では、地理的に異なる場所に多数のサーバーを配置することで、リスクを分散し、自然災害が1つの地域で発生した場合にアーキテクチャを別のサーバーにフォールバックできるようにします。
注: これは、Active-ActiveGeo-Distributionを備えたデータベースを使用して簡単に実現できます。
フェイルオーバーソリューションを使用する
高可用性アーキテクチャには通常、フェイルオーバー機能を提供する多数の疎結合サーバーが含まれます。フェイルオーバーは、プライマリシステムの機能がダウンしたときに自動的に利用されるバックアップ操作モードと見なされます。
ロードバランサーを実装する
前述のように、ロードバランサーは、ダウンタイムのリスクを軽減するために、着信トラフィックをさまざまなサーバーに分散します。このソリューションを完全に最適化するために、ニーズに合わせて調整されたアルゴリズムを利用するようにロードバランサーを構成してください。
データ同期が目標復旧時点(RPO)を満たしていることを確認します
RPOは、組織に害を及ぼすことなく失う可能性のあるデータの最大量のマーカーです。これは、ビジネス全体のデータ損失許容度を強調し、時間単位で測定される傾向があります。 1分または1日。
RPOを60秒以下に設定すると、最大の可用性を維持するのに役立ちます。そうすることで、一次ソースに障害が発生した場合でも、60秒を超えるデータが失われることはありません。
高可用性アーキテクチャにおけるRedisの役割
Redis Enterpriseは、最大の可用性を実現しようとしている大企業にとって強力なソリューションです。これは、ハードウェア障害とクラウド停止のリスクを軽減しながら、エリートの自動データベース復元力を提供するファイブナインの可用性を保証するリアルタイムデータプラットフォームです。
Redis Enterpriseは、最もミッションクリティカルなエンタープライズアプリケーションの高可用性のニーズを満たします。アクティブ-アクティブジオディストリビューション、自動フェイルオーバー、インテリジェントクラスタリング、シェアードナッシングアーキテクチャ、グローバルディストリビューションを使用して、99.999%の可用性を提供する業界をリードする機能を提供します。
高可用性を実現する方法について詳しく知りたいですか?
-
13年後– Redisには新しいアーキテクチャが必要ですか?
Redisは基盤技術であるため、代替アーキテクチャを検討している人を時々目にします。数年前、これはKeyDBによって提起され、最近、新しいプロジェクトであるDragonflyが、Redisと互換性のある最速のインメモリデータストアであると主張しました。これらのプロジェクトは、議論や議論に値する多くの興味深い技術やアイデアをもたらすと信じています。ここRedisでは、Redisが最初に設計されたアーキテクチャの原則を再確認する必要があるため、この種の課題が気に入っています(Salvatore Sanfilippo、別名antirezへのヒント)。 Redisのパフォーマンスと機能を革新および向
-
OELでの高可用性のためにOracleFormsandReportsをインストールおよび構成します
このブログでは、Oracle®FormsandReportsバージョン12.2.1.3.0をOracle Enterprise Linux(OEL)バージョン7.2サーバーにインストールして構成し、高可用性を確保する方法を紹介します。 次の図は、高可用性モデルを示しています。 この高可用性モデルを使用するには、次のタスクを実行する必要があります。このブログで詳しく説明しています。 アプリケーションノード(node1およびnode2)にWebLogic®Serverバージョン12.2.1.3をインストールする準備をします。 JDK®1.8をインストールします。 WebLogicServ