ミッション クリティカルなデータベースをすべて 1 つのインスタンスに統合してライセンス費用を節約したい場合、どのようなリスクが考えられるでしょうか。また、これに関する優れた記事やケース スタディはありますか? 私はこれがひどい考えであることを認識していますが、これを実行したいと考えており、必要に応じてハードウェア リソースを最大限に活用しようとする人がいます。私は彼に定量化できる何か、または彼がこれをしないように導くことができるいくつかの記事を提示しようとしています.
Billing、Dynamics CRM、およびトランザクションを追跡するための社内構築アプリケーションを含む 3 つの大きなミッション クリティカルなデータベースがあります。これらは、中小企業向けの大容量データベースです。これが間違った道であることを誰かに納得させるために、定量化できる、または優れたケーススタディのサポートが必要です。この人を説得する方法についての他のアドバイスも役に立ちます。
答えは異なります。一見、それは悪い考えのように見えるかもしれません。一方、目標がすべてを1つのサーバーに統合し、そのサーバーをリモート環境に複製することである場合は、より信頼性の高いシステムへの道を進んでいます。IT部門は、ミッションクリティカルなサーバーを地形全体に分散させるよりも、すべてを1か所にまとめることを好むかもしれません。
大きな問題の1つは、より大きなマシンの必要性です。したがって、システムのいずれかがマシンのサイズに依存しないライセンスを持つソフトウェアを使用している場合、より大きなサーバーが必要になるため、より多くのお金を費やすことになる可能性があります。たとえば、SASライセンスでこれが発生するのを見てきました。
ただし、おそらく最大の問題は、社内で開発されたか外部ベンダーから開発されたかにかかわらず、さまざまなアプリケーションがおそらくさまざまな開発サイクルにあることです。したがって、ハードウェア/オペレーティングシステム/ソフトウェアの更新は悪夢になる可能性があります。Aの修正または拡張機能にはOSパッチが必要な場合がありますが、OSパッチはBでテストされていません。このメンテナンスの問題が、個別のサーバーを強く推奨する理由です。
とはいえ、ミッションクリティカルなアプリケーションはまさにそれであり、ミッションクリティカルです。推進要因は、ハードウェアで数ドルであってはなりません。推進要因は、信頼性、保守、パフォーマンス、持続可能性、および回復である必要があります。
Oded、Catcall、および Gilbert によるコメントは的を射ています。
私が IT 取引を学んだ銀行は、単一の DBMS と単一のトランザクション プロセッサを実行する単一の MVS (後の Z/OS) メインフレームでコア ビジネス全体を実行していました (TSO をトランザクション プロセッサとして数えない限り)。
トランザクション プロセッサは定期的に (たとえば、1 日に 1 回) ダウンしました。銀行は常に 1 分もかからずに稼働を再開したため、銀行が破綻することはありませんでした。走行距離はさまざまですが、1 日の営業時間の 1 分 (480 分、または 0.25% 未満) を失うことは、実際には危険なほどの混乱ではありません。
単一の DBMS も時々 (たとえば、月に 2 回) ダウンしました。sysprogs が「DBMS がダウンしています」とフェンス越しにヘルプデスク担当者に向かって叫んでいるのを今でも聞くことができます。銀行は常に数分で稼働を再開したため、銀行が破綻することはありませんでした。走行距離はさまざまですが、毎月数分のビジネス時間を失うことは、実際には危険なほど混乱するべきではありません.
銀行が本当に倒産寸前だったのは、開発チームが銀行の絶対的な中核事業の新しいプロジェクトを台無しにして、銀行が完全に廃業したかのようだったときでした (その実際の事業は) 3 日か 4 日続けて。これは 0.25% のビジネス時間の損失ではなく、ほぼ 100 倍の損失でした。
私の話の教訓？それらの2つ。(a) リスク評価 (= 確率評価) とリスク加重 (= 確率加重) コスト見積もりがすべてです。(b) SO で質問した場合 (これは、回答者が主題に関してあなたよりも専門知識を持っているという一種の認識/期待を意味します)、Oded や Catcall のような人々が正確で適切な簡潔な回答を提供します。重要なのは、その回答を裏付けるために論文やケース スタディを求めないことです。専門家の専門知識を受け入れたくない場合は、そもそもなぜわざわざ質問する必要があるのでしょうか。