ETL、プロダクション、開発-これらは異なるサーバーである必要がありますか？インスタンス？

Question

私は「偶然のDBA」になったと言うことができます。人々がこの会社を去り、私は今、突然、BIシステムの多くの側面を管理しています。

私の前任者は関係なくかなり混乱を残しましたが、私はハードウェアアーキテクチャと論理パーティション化の観点から前進する最良の方法を考えています。

SQL-Server Data Warehouseがあります。 ETLスクリプトがあります（同じサーバー上）。データベース開発用のTest-Production分割はありません。

私の質問：

ETLスクリプト（SSISおよびPentaho PDI）は、データウェアハウスと同じサーバーに配置する必要がありますか？

これは複雑な質問であることを理解しています。私の理解はこれです。

別個のETLサーバーの利点：信じられないことに、SSISとSQL Serverはメモリ管理を介してうまく機能せず、SQL Server自体が最適に機能します。 ETLプロセスのニーズはまったく異なるため（バックアップのニーズがはるかに少なく、ストレージのニーズがはるかに少ない）、スケーラビリティと最適化は、通常、個別のETL環境を優先します。

短所：ハードウェアの追加コスト。 SSISの場合、追加のSQL Serverライセンスコスト（分離された場合は追加のライセンス）がかかるため、Standardエディションの場合は追加で900ドル、エンタープライズの場合は追加で13,000ドルなどです。また、データウェアハウスは日中のみ（開発者によって）使用されます-ETLは夜間にのみ実行されます-オーバーラップはほとんどありません。潜在的にバックアッププロセスのみが干渉する可能性があります。したがって、おそらく「競争」の側面は誇張されており、リソースプーリング（より多くのCPUハードウェアの場合、ハードウェアに関してはIS FRUGAL）が有利です）。

同じ質問ですが、テスト環境と本番環境です。

データベース（1つ下）またはサーバー（1つ上）の分離とは対照的に、「インスタンス」の分離のポイントは正確に何ですか？

私はそれらがより広い構成オプションを持っていると思いますが、サーバーも同じ物理ハードウェア/コンピューターで実行できます。 2つのサーバーまたは2つのインスタンスによるTest/Prodデータベースの分離の利点は何ですか？単純化のために構成を犠牲にしている2つのインスタンスを使用しますか？

Tony Hinkle · Answer

私たちが本当に難しいと考えた場合、おそらく100の理由がありますが、他の人のことを考えようとしないほど重要な理由はほんのいくつかあります。

リソース：まだすべてのメモリ、CPU、またはI/Oを使い果たした非実稼働サーバーで誰かが何かをしたことがない場合、続行すると最終的にそれが発生しますITで十分に長く働くこれが本番環境で発生することは望ましくありません。ええ、開発者は、本番ETLプロセスが実行されている夜間には、期限に間に合うまでテストを行いません。リソースの管理、個別のインスタンスを使用する場合でも、十分な長さの時間が経過すると（そうだとすれば、申し訳ありませんが）同じボックスでそれらを実行することはできません。
Security：理想的には、SQLログインを使用しないすべてのアクセスに対してActive Directoryグループを用意する必要があります。開発とプロダクションが同じインスタンス上にある場合、開発者全員がプロダクションインスタンスにアクセスできます。理想的には、本番インスタンスにログインすることもできる限り少ない人に許可したい
変更：すべての環境が同じシステムを使用している場合、テストできる変更は限られています。すべてが同じインスタンス上にある場合、新しいサービスパックまたは累積的な更新をテストできません。
The Future：各環境に個別のシステムがある場合、将来のニーズに対応できる可能性が高くなります。たとえば、非本番システムを本番システムから分離することは、セキュリティ上の目的で行われています。したがって、ワークステーションはdevおよびprodと通信できますが、devおよびprodサーバーは通信できません。それがすべて同じシステム上にある場合、これを行うことはできません。
事故の確率の低下：開発環境にあるすべてのサーバー、データベース、SQLログインなどの名前に「dev」がある場合、誰かが誤って何かを実行する可能性ははるかに低くなります生産中。資格情報が同じ名前で、その後、サーバー名の入力ミスが原因で本番環境がダウンした場合、ホラーストーリーはたくさんあります。

複数のインスタンスを使用することは確かに正しい方向への一歩ですが、リソースの競合、OSアップデートの影響、OSへのセキュリティ変更、さまざまなドライババージョンなどをテストできないリスクが依然としてあります。

同じサーバーでSSISジョブを実行するかどうかについては、同じ原則が適用されます。理想的には、別のSSISサーバーを用意して、リソースの競合を回避します。これを十分に理解しているようです。追加のハードウェアライセンスとソフトウェアライセンスの費用を支払うことは、組織にとって価値があるかどうかはわかりません。それを管理者に提示し、それらが拒否した場合、1つのシステムで実行しているものが多すぎるために物事がうまくいかなくてもカバーされます。