高可用性専用サーバーソリューションのトップ5
公開: 2017-06-22高可用性専用サーバーとは何ですか?
典型的な専用サーバーは、高速インターネット接続に接続され、最先端のリモートデータセンターまたは最適化されたデータ施設に収容されている強力なコンピューターです。
高可用性専用サーバーは、冗長電源、完全冗長ネットワーク、RAIDディスクを備えた高度なシステムです。 タワーとバックアップにより、単一障害点のない最高の稼働時間と完全な信頼性が保証されます。
高可用性専用サーバーの構成
その名前が示すように、高可用性専用ソリューションは、あらゆるビジネスの固有のニーズを満たすように設計された、スケーラブルでカスタマイズされたホスティングソリューションです。
これらの構成は、ビジネスで重要なアプリケーション(最高の可用性を必要とするアプリケーション)を実行するためのフェイルプルーフアーキテクチャを提供するように注意深く設計されています。
可能な高可用性サーバー構成には、冗長ロードバランサーによって管理される複数のホストが含まれる場合があります。 レプリケーションホスト。 また、セキュリティと信頼性を高めるための冗長ファイアウォール。
高可用性サーバーがビジネスにとって重要である理由
今日、企業はインターネットに依存しています。 それに直面しましょう–わずかなダウンタイムでも、ビジネスに大きな損失をもたらす可能性があります。 そして、経済的損失だけではありません。 評判の喪失も同様に壊滅的なものになる可能性があります。
StrategicCompaniesによると、フォーチュン500企業の半数以上が毎週最低1.6時間のダウンタイムを経験しています。 これは、時間、利益、消費者の信頼を大きく損なうことになります。 あなたの顧客がオンラインであなたに連絡できない場合、彼らに関する限り、あなたは月にいるほうがよいでしょう。
考えてみてください。2013年にAmazon.comが30分間停止すると、同社は200万ドル近くの損失を被ったと報告されています。 これは1分あたり66,240ドルです。 アマゾンでなくても、計画外のダウンタイムはビジネスに悪影響を及ぼします。
通常のホスティングプロバイダーは、99%のサービス可用性を提供する場合があります。 理論的には、それは良いことのように聞こえるかもしれません。 しかし、1%不足していることを考えてみてください…これは、年間87時間(3。62日)のダウンタイムです。 ピーク時にダウンタイムが発生した場合、ビジネスの損失は悲惨なものになる可能性があります。
ダウンタイムを防ぎ、これらの損失を排除する最善の方法は、高可用性ホスティングソリューションを選択することです。
ハードウェアとソフトウェアの複雑なアーキテクチャに基づいて構築されているため、このシステムのすべての部分は互いに完全に独立して動作します。 言い換えれば、単一のコンポーネントに障害が発生しても、システム全体が崩壊することはありません。
非常に大量のリクエストや突然のトラフィックの急増に対応できます。 組織の規模とニーズに応じて拡大および縮小します。 あなたのビジネスは柔軟ですが、あなたのコンピュータシステムも柔軟であるべきではありませんか?
以下は、ビジネスアプリケーションをホストするために使用できる最高の高可用性ソリューションの一部です。
1.超高性能専用サーバー
ハイパフォーマンスサーバーは、特に最大のパフォーマンスを達成するように設計された、より大きなコンピューティング能力を備えたハイエンドの専用ソリューションです。 これらは、エンタープライズワークロードに対応するための理想的なソリューションです。
一般的な高性能専用サーバーは、次のもので構成されます。
- シングル/デュアル最新のIntelXeonE3またはE5シリーズプロセッサ。
- 64 GB〜256 GB RAM
- RAID 10を搭載した8〜24 TB SATA II HDD
- エネルギー効率が高く冗長な電源および冷却ユニット
- オフサイトバックアップ
上記のリストは、固有の要件に従ってカスタマイズ/アップグレードできる構成のサンプルにすぎないことに注意してください。 より多くの電力が必要な場合は、96台のドライブ、3 TBのRAM、および40以上の物理CPUコアを備えたセットアップを構築できます。
実世界のアプリケーション(ケーススタディ)
お客様の要件
既存の顧客の1人は、エンコードされたPHPおよびMySQLサーバーをバックエンドとして使用してフラッシュゲームをホストするハイエンドゲームサーバーを探していました。
最高の可用性を実現するために、フェイルオーバーを備えた2つのロードバランサーが必要でした。 それぞれに2つのWebサーバーと1つのデータベースサーバーが含まれています。
ウェブサイトの統計
- 8000-10000同時プレイヤー
- 100%の稼働時間要件
- 10GB以上のデータベースサイズ
AccuWebHostingによって提案されたソリューション
キャパシティプランニングチームは、Webサーバーとデータベースサーバーの前にデュアルロードバランサーを配置して、完全に冗長なインフラストラクチャを設計しました。
このセットアップは、ファイアウォールを介してWebサーバーのグループに接続されたロードバランサーを備えた2つのVMで構成されています。 データベースサーバーは、最速のディスクI /O操作のために超高速SSDドライブ上に構築されました。
フェイルオーバーの場合、リアルタイムミラーリングを使用してこのアーキテクチャの正確なレプリカを設定します。 プライマリシステムに障害が発生した場合、セカンダリセットアップがシームレスにワークロードを引き継ぎます。 それは正しい。 ダウンタイムはゼロです。
インフラストラクチャ図
2.負荷分散された専用サーバー
負荷分散
着信Webトラフィックをサーバーのグループ全体に効率的かつ介入なしで分散するプロセスは、負荷分散と呼ばれます。
この負荷分散機能を提供するハードウェアまたはソフトウェアアプライアンスは、ロードバランサーと呼ばれます。
ハードウェア/ソフトウェアロードバランサーを備えた専用サーバーは、負荷分散された専用サーバーと呼ばれます。
負荷分散はどのように機能しますか?
ロードバランサーはサーバーの前に配置され、訪問者の要求をサーバー間でルーティングします。 これにより、均等な分散が保証されます。つまり、すべてのサーバーの速度と容量の使用率を最大化する方法ですべての要求を実行する必要があり、サーバーの使用率が高すぎたり低すぎたりすることはありません。
顧客がWebサイトにアクセスすると、最初にロードバランサーに接続され、ロードバランサーがインフラストラクチャ内のWebサーバーの1つに顧客をルーティングします。 サーバーがダウンした場合、ロードバランサーはトラフィックを残りのオンラインサーバーに即座にリダイレクトします。
Webトラフィックが増加すると、負荷分散されたサーバーの既存のプールに新しいサーバーをすばやく簡単に追加できます。 新しいサーバーが追加されると、ロードバランサーは新しいサーバーへのリクエストの送信を自動的に開始します。 そうです–ユーザーの介入は必要ありません。
負荷分散の種類
負荷分散は、次のいずれかの方法で実行できます。
- DNSを介した負荷分散
- ハードウェアを介した負荷分散
- ソフトウェアによる負荷分散
DNSとの負荷分散
DNSサービスは、複数のサーバー間でWebトラフィックのバランスを取ります。 この方法でトラフィックの負荷分散を実行する場合、どの負荷分散アルゴリズムを選択できないことに注意してください。 常にラウンドロビンアルゴリズムを使用して負荷を分散します。
ハードウェアを介した負荷分散
これは、負荷分散の最もコストのかかる方法です。 トラフィックの負荷分散を処理する専用のハードウェアデバイスを使用します。
ほとんどのハードウェアベースのロードバランサーシステムは、アクセスのしやすさと構成の概要を可能にする負荷分散管理ツールを備えた組み込みLinuxディストリビューションを実行します。
ソフトウェアによる負荷分散
ソフトウェアベースの負荷分散は、サーバー間で負荷を分散するための最も信頼性の高い方法の1つです。 この方法では、ソフトウェアはさまざまなアルゴリズムを介して着信要求のバランスを取ります。
負荷分散アルゴリズム
インバウンド要求の負荷分散を実現するために使用できるアルゴリズムは多数あります。 負荷分散方法の選択は、サービスタイプ、負荷分散タイプ、ネットワークステータス、および独自のビジネス要件によって異なります。
通常、低負荷システムの場合は、単純な負荷分散方法(つまり、ラウンドロビン)で十分ですが、高負荷システムの場合は、より複雑な方法を使用する必要があります。 ロードバランサーで使用される業界標準の負荷分散アルゴリズムの詳細については、このリンクを確認してください。
Linuxでの負荷分散の設定
HAProxy(High Availability Proxy)は、Linuxマシン(Webサーバー、データベースサーバーなど)でロードバランサーをセットアップするために利用できる最良のツールです。
これは、Github、StackOverflow、Reddit、Tumblr、Twitterなどの最大のWebサイトで使用されているオープンソースのTCPおよびHTTPロードバランサーです。
また、メモリフットプリントが小さく、CPU使用率が低い高速で軽量のプロキシサーバーソフトウェアとしても使用されます。
以下は、Apache、NGINX、およびMySQLサーバーで負荷分散をセットアップするための優れたチュートリアルです。
- CentOS7でNginxのロードバランサーとしてHAProxyを設定する
- HAProxyを使用してApache用の高可用性ロードバランサーをセットアップする
- HAProxyを使用してMySQL負荷分散を設定する
Windowsでの負荷分散の設定
IIS Webサーバーとの負荷分散を設定するには、Microsoftの公式ドキュメントの下を確認してください。
IISで負荷分散を設定する
3.スケーラブルなプライベートクラウド
スケーラブルなプライベートクラウドは、独自のアーキテクチャを通じてセルフサービス、スケーラビリティ、および弾力性を提供するクラウドベースのシステムです。
プライベートクラウドは非常にスケーラブルです。つまり、より多くのリソースが必要な場合はいつでも、メモリ、ストレージスペース、CPU、帯域幅などのリソースをアップグレードできます。
最高レベルのセキュリティと制御を提供し、大企業にとって理想的なソリューションになります。 これにより、カスタム要件に最適なようにコンピューター、ストレージ、およびネットワークコンポーネントをカスタマイズできます。
プライベートクラウドの利点
強化されたセキュリティとプライバシー
すべてのデータは、専用アクセスを備えた専用サーバーに保存および管理されます。 クラウドがオンサイトの場合、サーバーは社内のITチームによって監視され、データセンターにある場合は、技術者が監視します。 したがって、物理的セキュリティはあなたの関心事ではありません。
完全冗長プラットフォーム
プライベートクラウドプラットフォームは、ハードドライブ、処理能力などの複数の障害を補うためのレベルの冗長性を提供します。プライベートクラウドがある場合、トラフィックの変動を処理するために物理インフラストラクチャを購入する必要はありません。
効率と制御
プライベートクラウドを使用すると、データとインフラストラクチャをより細かく制御できます。 専用のリソースがあり、サーバーの所有者以外は誰もサーバーにアクセスできません。
スケーラブルなリソース
各企業には一連の技術要件とビジネス要件があり、通常、企業の規模、業界、ビジネスの目的などに基づいて他の企業とは異なります。
プライベートクラウドを使用すると、独自の要件に従ってサーバーリソースをカスタマイズできます。 また、必要に応じてサーバーのリソースをアップグレードすることもできます。
プライベートクラウドのデメリット
料金
パブリッククラウドやシンプルな専用サーバーのセットアップと比較すると、プライベートクラウドはより高価です。 ハードウェアとリソースへの投資も必要です。
プライベートクラウドをレンタルすることもできますが、コストは同じかそれ以上になる可能性が高いため、これは利点ではない可能性があります。
メンテナンス
プライベートクラウドの購入またはレンタルは、コストの一部にすぎません。 明らかに、購入の場合、開始時に多額の現金が必要になります。 賃貸している場合は、継続的な月額料金がかかります。
ただし、これらのコストを超えても、メンテナンスとアクセサリを検討する必要があります。 プライベートクラウドには、十分な電力、冷却設備、サーバーを管理するための技術者などが必要です。
十分に活用されていない
サーバーリソースを利用していない場合でも、プライベートクラウドの全費用を支払う必要があります。 所有するかレンタルするかにかかわらず、容量が十分に活用されていない場合のコストは気が遠くなる可能性があるため、プロセスの最初に適切にスケーリングします。
複雑な実装
技術に精通していない場合は、プライベートクラウドの維持が困難になる可能性があります。 インフラストラクチャを管理するには、クラウドの専門家を雇う必要がありますが、さらに別のコストがかかります。
LinuxおよびWindowsプライベートクラウドプロバイダー
クラウドプロバイダーは、Windowsまたは任意のLinuxディストリビューションのいずれかのOSを選択するオプションを提供します。 以下は、プライベートクラウドソリューションプロバイダーの一部です。
- AccuWebHosting
- アマゾンウェブサービス
- Microsoft Azure
- ラックスペース
独自のプライベートクラウドのセットアップ
独自のプライベートクラウドをセットアップするために利用できる多くの有料およびオープンソースツールがあります。
- OpenStack
- VMware vSphere
- VMmanager
- OnApp
- OpenNodeクラウドプラットフォーム
OpenStackは、パブリッククラウドとプライベートクラウドの両方にIAAS(Infrastructure As A Service)を提供するオープンソースプラットフォームです。
ここをクリックして、独自のプライベートクラウドインフラストラクチャを展開する方法に関する完全なインストールガイドをご覧ください。 CentOSまたはRHEL7の単一ノードでOpenStackを使用します。
4.フェイルオーバー
フェイルオーバーとは、プライマリサーバー/ネットワークに障害が発生したときに、スタンバイサーバーまたはネットワークに即座に切り替えることを意味します。
プライマリホストがダウンしたり、メンテナンスが必要になったりすると、ワークロードは自動的にセカンダリホストに切り替えられます。 これはシームレスである必要があり、ユーザーはそれが発生したことに完全に気づいていません。
フェイルオーバーは単一障害点(SPoF)を防止するため、1秒のダウンタイムなしでシステムをオンラインにする必要があるミッションクリティカルなアプリケーションに最適なオプションです。
フェイルオーバーはどのように機能しますか?
驚いたことに、自動フェイルオーバーシステムのセットアップは非常に簡単です。 フェイルオーバーインフラストラクチャは、プライマリサーバーとセカンダリサーバーの2つの同一サーバーで構成されます。 両方のサーバーが同じデータを提供します。
3番目のサーバーが監視に使用されます。 プライマリサーバーを継続的に監視し、問題を検出すると、トラフィックがセカンダリサーバーに転送されるように、WebサイトのDNSレコードを自動的に更新します。
プライマリサーバーが再び機能し始めると、トラフィックはプライマリサーバーにルーティングされます。 ほとんどの場合、ユーザーはダウンタイムやサーバー応答の遅れに気付くことさえありません。
フェイルオーバータイプ
コールドフェイルオーバー
コールドフェイルオーバーは、1つのシステムを別の同一のプライマリシステムのバックアップとして使用する冗長方式です。 コールドフェイルオーバーシステムは、プライマリシステムに障害が発生した場合にのみ呼び出されます。
したがって、コールドフェイルオーバーとは、最初のサーバーがシャットダウンされた後にのみ2番目のサーバーが起動されることを意味します。 明らかに、これは、切り替え中に少量のダウンタイムに耐えることができなければならないことを意味します。
ホットフェイルオーバー
ホットフェイルオーバーは、1つのシステムが同一のプライマリシステムと同時に実行される冗長な方法です。
プライマリシステムに障害が発生すると、ホットフェイルオーバーシステムがすぐに引き継ぎ、プライマリシステムを置き換えます。 ただし、データは引き続きリアルタイムでミラーリングされ、両方のシステムが同一のデータを持つようにします。
セットアップフェイルオーバー
フェールオーバークラスターをセットアップしてデプロイするには、以下のチュートリアルを確認してください。
- WindowsServer2012でフェールオーバークラスターをセットアップする
- CentOSで高可用性クラスターを構成する
- Linuxでのクラスタリングの設定に関する完全ガイド
利用可能なソリューション
フェールオーバークラスターの主要なプロバイダーは、次の4つです。
- Microsoftフェールオーバークラスター
- RHELフェールオーバークラスター
- VMWareフェールオーバークラスター
- Citrixフェールオーバークラスター
フェイルオーバーの利点
- フェールオーバーサーバーのクラスタリングは、完全にスケーラブルなソリューションです。 リソースはクラスターに追加したり、クラスターから削除したりできます。
- クラスタの専用サーバーでメンテナンスが必要な場合は、他のサーバーがその負荷を処理している間、そのサーバーを停止できます。 したがって、メンテナンスが容易になります。
フェイルオーバーのデメリット
- フェールオーバーサーバーのクラスタリングでは、通常、管理と監視のためにより多くのサーバーとハードウェアが必要になるため、インフラストラクチャが増加します。
- すべてのサーバータイプをクラスター化できるわけではないため、フェールオーバーサーバーのクラスタリングは柔軟ではありません。
- クラスタ化された設計でサポートされていない多くのアプリケーションがあります。
- 費用対効果の高いソリューションではありませんが、 高価になる可能性のある優れたサーバー設計が必要なためです。
5.高可用性クラスター
高可用性クラスターは、サーバーノードに障害が発生したり、過負荷が発生したりした場合に最小限のダウンタイムで利用できるサーバーアプリケーションをサポートするサーバーのグループです。
負荷分散、フェールオーバーサーバー、バックアップシステムなどの理由で、高可用性クラスターが必要になる場合があります。 クラスター構成の最も一般的なタイプは、アクティブ-アクティブおよびアクティブ-パッシブです。
アクティブ-アクティブ高可用性クラスター
少なくとも2つのノードで構成され、どちらも同じサービスをアクティブに実行しています。 アクティブ-アクティブクラスターは、真の負荷分散を実現するのに最適です。 ワークロードはノード全体に分散されます。 一般に、応答時間と読み取り/書き込み速度が大幅に向上します。
アクティブ-パッシブ高可用性クラスター
アクティブ-パッシブも少なくとも2つのノードで構成されます。 ただし、すべてのノードが同時にアクティブなままになるわけではありません。 セカンダリノードはパッシブモードまたはスタンバイモードのままです。 一般に、このクラスターはフェールオーバークラスター環境に適しています。
高可用性クラスターのセットアップ
高可用性クラスターをセットアップするための優れたチュートリアルを次に示します。
- CentOSでの高可用性クラスターの構成
- CentOS 7 /RHEL7で高可用性クラスターを構成する
利用可能なソリューション
高可用性サービスの専門家である非常に有名なベンダーが世の中にあります。 それらのいくつかを以下に示します。
- デルのWindows高可用性ソリューション
- MicrosoftおよびLinuxクラスター向けのHP高可用性(HA)ソリューション
- VMwareHAクラスター
高可用性クラスターの利点
ダウンタイムに対する保護
HAソリューションでは、クラスターのいずれかのサーバーがオフラインになると、すべてのサービスがアクティブなホストに移行されます。 サーバーをオンラインに戻すのが早ければ早いほど、ビジネスに戻るのも早くなります。 これにより、ビジネスの生産性が低下するのを防ぐことができます。
最適な柔軟性
高可用性ソリューションは、ビジネスで24時間365日の可用性とセキュリティが必要な場合に、より高い柔軟性を提供します。
ダウンタイムコストを節約
サーバーをオンラインに戻すのが早いほど、ビジネスに戻るのも早くなります。これにより、ビジネスの生産性が低下するのを防ぐことができます。
簡単なカスタマイズ
HAソリューションでは、フェイルオーバーサーバーに切り替えて本番環境を継続するのはほんの数秒です。 要件に応じてHAクラスターをカスタマイズできます。 データを数分または数秒で最新の状態に設定できます。 さらに、データ複製スキーム、バージョンは必要に応じて指定できます。
高可用性クラスターの短所
インフラストラクチャの継続的な成長
フェイルオーバーと負荷分散を実現するには、多くのサーバーと大量のハードウェアが必要です。 これにより、インフラストラクチャが増加します。
アプリケーションはサポートされていません!
HAクラスタリングは、ハードウェアレベルで多くの柔軟性を提供しますが、すべてのソフトウェアアプリケーションがクラスター環境をサポートしているわけではありません。
高い
HAクラスタリングは、費用効果の高いソリューションではありません。 あなたが必要とするより洗練されたものであるほど、あなたはより多くのお金を投資する必要があります。
6.AccuWebHostingによって構築された複雑な構成
お客様の要件
1秒あたり1000のHTTPリクエストのピーク負荷、1日あたり15,000を超える訪問者、10秒未満で3倍の負荷を処理できるeコマースWebサイト。 ピーク時と新製品の発売時には、Webサイトへのアクセス数は2倍になります。
ウェブサイトの統計
- 40K製品および製品関連記事
- 40 GBの静的コンテンツ(画像、ビデオ、およびWebサイト要素)
- 6GBのデータベース
私たちが提供したソリューション
負荷を処理し、最大の可用性も確保するために、高可用性クラウドインフラストラクチャを提案しました。 負荷を分散するために、セットアップの前に2台のロードバランサーサーバーをマウントし、その上に負荷分散されたIPアドレスを配置しました。
予想されるトラフィックを吸収するために、合計8台のWebサーバー、3台の物理専用サーバー、および5台のクラウドインスタンスを導入しました。 セットアップは、rsyncクラスターを介してさまざまなコンポーネント間で同期されるように構成されました。
クラウドインスタンスは、追加の物理サーバーに関連するコストを発生させることなく、ピークトラフィックの負荷に応じて追加または削除できる方法で使用されました。
各クラウドインスタンスには、ユーザーにスムーズなWebサイトエクスペリエンスを提供するために、Webサイト全体(40GBの静的コンテンツ)が含まれていました。
6 GBのデータベースは、マスター専用サーバーでホストされていました。このサーバーは、マスターサーバーに障害が発生したときに引き継ぐために、セカンダリスレーブサーバーで複製されました。 これらのDBサーバーは両方とも、読み取り/書き込みパフォーマンスを向上させるためにSSDディスクを備えています。
15人の開発者とコンテンツ作成者のチームが、専用サーバーでホストされているバックオフィスサーバーを介してコンテンツを更新します。 チームによって行われた変更はすべて、本番環境とデータベースのrsyncによって伝播されます。
インフラストラクチャ全体は、高可用性クラウドVPSにインストールされているZabbixによって監視されていました。 Zabbixは、インフラストラクチャサーバーから提供されたデータを監視し、一連のグラフを生成して、RAM使用量、負荷平均、ディスク消費量、およびネットワーク統計を示します。 Zabbixは、使用量のいずれかが しきい値、またはサービスのいずれかがダウンした場合。
結論
これまで見てきたのは、負荷分散、フェイルオーバー、高可用性のセットアップなど、小規模から複雑なビジネスITソリューションを構築するためのさまざまなテクノロジーです。
また、実際のアプリケーションやケーススタディもいくつか見てきました。 これらのケーススタディは、最適な高可用性インフラストラクチャを完成させるのに役立ちます。
ビジネス用に新しいインフラストラクチャを購入することを計画している場合、または既存のインフラストラクチャをアップグレードしたい場合は、AccuWebHostingをいつでも利用できます。 また、cloudsmallbusinessserviceのトップ10リストで最も推奨されるホスティングプロバイダーとしてリストされています。
カスタム要件がある場合は、コメントセクションで言及するか、テクニカルセールスチームとライブチャットすることができます。 希望する高可用性ソリューションについて話し合うために、24時間体制で対応しています。