タグ付けされた質問 「high-availability」

高可用性は、システムまたはコンポーネントに障害が発生した場合の可用性を保証するための冗長性の度合いを伴うことが多いアーキテクチャ上の考慮事項です。

1
ZFSヘッドノードをデータベースサーバーとして使用していますか？
ここに示すように、Nexentaの推奨アーキテクチャに基づいて、高可用性クラスタ共有ストレージにデュアルヘッドZFS-backed NASを使用しています。 1 JBODのディスクは単一の4 TB Postgresデータベースのデータベースファイルを保存し、他のJBODのディスクは20 TBの大きな未加工バイナリフラットファイル（大きな恒星オブジェクトの衝突シミュレーションのクラスター結果）を保存します。つまり、PostgresファイルをバッキングするJBODは主にランダムなワークロードを処理し、シミュレーション結果をバッキングするJBODは主にシリアルワークロードを処理します。どちらのヘッドノードにも256 GBのメモリと16コアがあります。クラスターには約200のコアがあり、それぞれがPostgresセッションを維持しているため、約200の同時セッションが予想されます。 ZFSヘッドノードをクラスターのミラーリングされたPostgresデータベースサーバーのペアとして同時に機能させることが、セットアップで賢明かどうか知りたいのですが。私が見ることができる唯一の欠点は次のとおりです。 インフラストラクチャのスケーリングの柔軟性が低下します。 冗長性のレベルがわずかに低くなります。 PostgresのメモリとCPUリソースが制限されています。 ただし、私が理解している利点は、ZFSは自動フェールオーバーにかなりとんでもないことであり、ヘッドと一緒に失敗するため、ヘッドノードが失敗したかどうかを各Postgresデータベースサーバーに理解させるために多くの作業を費やす必要はありません。ノード。
4
Ganeti vs Proxmox [終了]
現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、議論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 私は小さなソフトウェアハウスのシステム管理者です。サーバーを仮想化します。これを行う主な理由は、可能な限り最高の稼働時間を提供することですが、おそらくリソースの使用率も増加します。 2つのサーバーがあります。1つは開発用のVMがほとんどなく、ビルドサーバーとしても使用されている（Jenkinsマスター、ビルドエグゼキューター）。2番目のサービスでは、いくつかの重要なサービス（コードリポジトリ、課題追跡）がほとんどありませんでした。 これらのマシンを使用して2つのノードクラスタを作成し、各サービスにVMを作成したいと思います。ノード間でマシンを移動できるように、DRBDを使用したいと思います。 いくつかの調査の後、私の候補者はProxmoxとGanetiです。私の状況ではどちらが良いでしょうか？私はProxmoxのシンプルさ（特にインストールのシンプルさ）が好きですが、Ganetiを使用する正当な理由があるのでしょうか？
11
Linux向けの優れたフェイルオーバー/高可用性ソリューション？[閉まっている]
閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 4年前休業。 ロックされています。この質問とトピックへの回答はロックされています。質問はトピックから外れていますが、歴史的に重要です。現在、新しい回答や相互作用を受け入れていません。 障害（サーバーのハングまたはクラッシュ）が発生した場合に、あるサーバーから別のサーバーにアプリケーションを移行する必要があるいくつかのケースがあります。 solarisでは、これをVCS（Veritas Cluster Server）で行います。Linuxにはどのようなオプションがありますか？ それぞれの設定/保守にかかる労力のレベルまたはコスト（ある場合）を示してください。 -詳細を追加- 複雑さのレベルを知るには： 障害が発生したサーバーは予告なしにハングまたはクラッシュする可能性があり、「ping可能」である可能性があります リカバリサーバーは、フェイルオーバー時にアプリケーションを起動する必要があります 失敗したサーバーのブート/電源の再投入は、リカバリサーバーと干渉しないようにパッシブになります。 これはデータベースではなくデータ収集ノードまたは計算ノードであるため、より単純なソリューションが機能する可能性があります。 -さらに詳細（申し訳ありません）- 共有ストレージはオプションではありませんが、あるサーバーから別のサーバーに移行する必要がある状態（ある場合）はそれほど多くありません。rsyncを介して2つのサーバーの同期を維持します。 これまでのすべての投稿をありがとうございました。
5
高可用性仮想化環境のセットアップ
プロジェクトでは、WebショップとCMSシステムの高可用性セットアップを計画するタスクがあります。ただし、当然のことながら、プロジェクトの予算は限られています。したがって、ハイエンドのソリューションは予算に収まらない可能性があります。 Webサーバー（CMS、ショップ）を実行する2台のマシン、データベースを実行する1台のマシン、およびパートナーに注文を配信するために必要なFAXサーバーを実行する1台のマシンがあります。すべてのシステムでLinuxが実行されています。これらのコンポーネントはすべて高可用性である必要があり、透過的なフェイルオーバーをサポートする必要があります。 ハードウェアコストを削減するために、仮想化環境について考えます。世の中にはたくさんの情報がありますが、何から始めたらよいのか正確にはわかりません。少なくともサーバーが仮想マシンのホストとして必要であることは明らかであり、単一障害点はありません。 高可用性をサポートするための最善の方法はどれですか。 最初の質問は、どの仮想化ソリューションがこの状況で最適かということです。なんらかの管理インターフェースが必要です。実行中の仮想マシンをあるホストから別のホストに移動して、ホストのメンテナンスを行えるようにする方法が必要です。1つのホストに障害が発生した場合でも仮想マシンを引き続き使用できるように、何らかのメカニズムが必要です。ここで有効な解決策についてアドバイスできますか？ 共有ファイルストレージは、ほとんどの場合、高可用性の前提条件のようです（VMware vSphereはかなり高価です）。ただし、2台のサーバーをセットアップに追加して冗長なNFSファイルストアを提供するよりも、仮想マシンホストに多くのお金を投入した方がよいでしょう。2つの仮想マシンホストだけでうまくいく可能性はありますか？解決策は、これら2つをNFSホストとして使用することです。これを行うと、パフォーマンスの低下が大きくなりますか？ 編集：私は99,9％の可用性を目指しています。ただし、通常の営業時間があるため、24時間年中無休で稼働する必要はありません。これにより、操作にある程度のスペースが確保されます。何らかの形で保証する必要がある可用性の期間は、午前10時から深夜0時までです。
9
小規模な操作の単一障害点に関する質問
障害が発生したときにオンラインになるのを待機しているクラスターまたはスペアサーバーを用意する余裕がない場合は、1台のサーバーが提供するサービスを2台のサーバーに分割する可能性があります。したがって、サーバーAがダウンすると、クライアントは電子メールなどのアクセスを失う可能性があり、サーバーBがダウンすると、ERPシステムへのアクセスを失う可能性があります。 最初はこれの方が信頼性が高いように見えますが、単にハードウェア障害の可能性を高めるだけではありませんか？したがって、1つの障害が生産性に与える影響はそれほど大きくはありませんが、2倍の障害に備えることができます。 私が「ビーフが少ない」と言うとき、私が本当に意味しているのは、品質の低下ではなく、コンポーネントのスペックの低下です。したがって、視覚化用に1台のマシン仕様を使用するのに対して、それぞれの負荷を軽減するために2台のサーバー仕様を作成しました。 多くの場合、サービスを維持するためにクラスタリングまたは移行を使用できるように、SANが推奨されます。しかし、SAN自体はどうですか？障害が発生する場所にお金をかけるとしたら、それは基本的なサーバーハードウェアではなく、ストレージに関係しています。なんらかの冗長SANがない場合、それらの冗長サーバーは私に大きな自信を与えません。個人的には、小規模な運用では、冗長コンポーネントとローカルドライブを備えたサーバーに投資する方が理にかなっています。SANの価格と柔軟性が費用対効果に優れている大規模な運用にはメリットがあります。しかし、小さな店では、少なくともフォールトトレランスではなく、私は議論を見ていません。
3
ESXi HAクラスターの共有ストレージオプション
ESXi HAクラスターをサポートするための共有ストレージオプションの推奨事項を探しています（製品/ブランド/モデルの推奨事項は求めていません -これはここのルールに違反していることを知っています）。私は尋ねるための技術勧告。 私が働いている会社は中小企業です。現時点では、カスタム開発されたアプリケーションを実行する1つのHP DL380 G9とDAS、ESXi 6.0を使用しています。現在、最も経済的なオプションを使用してHA / FTを実現する方法を検討しています。私は1人のITチームであり、頻繁に出張しているため、手動でフェイルオーバー/復元することはできないため、HA / FTが必要です。 HA / FTを実現するには、最低2つのESXiホスト（物理サーバー）と共有ストレージが必要であることを理解しています。これは興味深いところです。最も安価なエントリーレベルのストレージアレイでさえ、おそらく私たちにとってはやり過ぎです。私たちのストレージ容量の要件はおそらく約200GBであり、少なくとも5年間はその倍増は見られません。しかし、HA / FTには共有ストレージが必要です。 したがって、私のオプションについての推奨は本当に本当にありがたいです。ありがとう。
3
完全に再起動せずにハートビートでシステムに新しいIPアドレスを追加する方法はありますか？
高可用性のためにハートビートを利用します。ハートビートクラスターに追加のIPアドレスを追加したいのですが、プロセス中にクラスターを完全に再起動したくありません。「haresources」ファイルの再解析とそのアクションの実行を促す信号をハートビートに送信できますか？heartbeat -rはトリックを実行していないようです。
7
cronジョブのフェイルオーバーを実行するにはどうすればよいですか？
2つのDebianサーバーを使用して、一度に1つのサーバーでのみ呼び出すことができるcronジョブ用の強力なフェイルオーバー環境をセットアップする必要があります。 /etc/cron.d内のファイルを移動するとうまくいくはずですが、そのようなアクションを実行する簡単なHAソリューションはありますか？そして、可能であればハートビートではありません;）
3
24時間365日のシステムでデータベースのメンテナンスを実行する方法
私は、パートタイムDBAの役割を引き継いだソフトウェア開発者です。私は、SQL Server 2008上の小規模で大容量の24時間365日のデータベースによるアプリケーションバックエンドを担当しています。 DBには他にもデータがありますが、重要な部分は50GB、7.5Mの行テーブルであり、ピーク負荷時に1秒あたり100Kのリクエストを処理します。これは99％以上の読み取りトラフィックですが、書き込みは一定であり、必要です。 メンテナンスウィンドウなしで定期的なメンテナンスを実行できる必要があります。インデックスの再構築、古いデータを削除するジョブ、Windows Update、またはハードウェアのアップグレードを言ってください。私が見たアドバイスのほとんどは、「メンテナンスウィンドウの作成」に沿っています。私は感情に感謝していますが、別の方法があることを願っています。この問題が解決する場合、新しいハードウェアを購入したり、データベース、クライアント（Webサービスサーバーのセット）、およびアプリケーションコード（ADO.NET + ASP.NET）の多くを変更することができます。 私は、ウォームスペア（または3番目のサーバー）を使用してメンテナンスを行い、それを運用環境に "スワップ"するという方針に沿って考えていました。 1現在のトランザクションログを含むバックアップを復元して、スペアを同期します。 2メンテナンスタスクを実行します。3予備サーバーに接続するようにクライアントを再構成します。既存の接続は1分程度で終了します。4予備サーバーが本番サーバーになりました。 残っている問題は、新しい実稼働サーバーがメンテナンスの実行にかかった時間が古くなっていることです。ステップ2と3の間で、元の実稼働サーバーを変更のキューに入れ、それらをスペアにマージする方法はありますか？他のアイデアはありますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.