データベースエンジンとSSISDBアーキテクチャに関するアドバイス

Question

SQL Server 2017のデータベースエンジンとIntegration Servicesコンポーネントに関するアーキテクチャに関するアドバイスを探しています。既存のSQL Server環境はアップグレードが予定されており、これまで理想的とは言えない方法で使用されてきました。新しいSQL Server環境へのアップグレードが近づいている今、システム管理者としてこの機会を利用して、既存のアーキテクチャを再考し、より堅牢なフレキシブル環境を提供したいと考えています。

現在の環境

2ノードのWindowsフェールオーバークラスターで実行されているSQL Server 2012 Enterpriseインスタンス。データベースエンジンはクラスター化されており、DTS=パッケージはクラスター化されたボリュームに格納され、これらのパッケージはSQL Serverエージェントを介してジョブとして実行されます。明示的なIntegration Servicesコンポーネントは使用しません。

問題

データウェアハウスを管理し、DTSパッケージを作成/管理するスタッフは、RDPを介してクラスター化されたサーバーノードで直接作業することを伝統的に主張してきました。これにより、サーバーを担当するシステム管理者にアクセスの問題が生じます。データスタッフもさまざまなソフトウェアツールを必要とするため、時間の経過とともに永続的なディスク領域の問題が発生します。さらに、これらのソフトウェアツールの多くはクラスタに対応しておらず、1つのノードにしかインストールされないため、事実上クラスタが機能しなくなっていますその結果、計画的または計画外のフェイルオーバーが発生すると、ほとんどのジョブはクラスター対応ではないローカルソフトウェアに依存しているため、ほとんどのジョブが失敗するため、元のプライマリノードをできるだけ早くオンラインに戻す必要があります。

提案されたソリューション

独自のクラスターにデータベースエンジンのみをインストールし、スタッフがRDPアクセスを許可しないようにします。 SQL Serverクラスター化インスタンスのエンドポイントURLのみを受け取ります。 Integration Servicesコンポーネントを別のサーバーにインストールし、ファイルシステムではなくSSISDBカタログを使用してパッケージを格納することを提案します。私の理解では、SSISDBを使用することには多くの利点があるということです。

質問

1. これは、RDPアクセスの問題を別のサーバーにシフトするだけです。データスタッフはパッケージをリアルタイムで共同で使用し、すべて同じソフトウェアツールに依存しているため、同一の共有環境を提供するにはサーバーに直接アクセスする必要があると主張します。ローカルワークステーションで開発ツールを使用し、SSMSを使用してSSISに接続し、ジョブを発行およびスケジュール/実行できる、より近代的な設計アプローチが必要だと私は信じています。パッケージに依存するソフトウェア（ftp、ssh、Perl、pythonなど）は、SSISのサーバー管理者によってインストールおよび管理されます。パッケージはSSISDBに格納されるため、従来パッケージファイルを格納していた共有ストレージが不要になり、直接RDPアクセスの必要がなくなります。私の信念は論理的ですか、それともデータ開発者がサーバーに直接アクセスするためのいくつかの議論がありますか？
2. これで、パッケージは従来のようにフェールオーバークラスターの一部ではなくなったため、SSISDBが単一障害点になります。このコンポーネントに高可用性を組み込むにはどうすればよいですか？私はSSISのスケールアウト機能について読みましたが、それはフォールトトレランスというよりは負荷のバランスをとることについてのようです。 AlwaysOn可用性グループについて読み始めましたが、それが解決策になるでしょうか？

どんなデザインアドバイスでも大歓迎です。ありがとう。

Answer 1

これはプロセスの変化と同様に文化の変化です。したがって、管理サポートを得ることが重要であり、最終的にはある程度の技術的抵抗からあなたを守り、この戦略的変化がすべての人の生活を改善する方法を放送するのに役立ちます。

SSISカタログの特定のケースに入る前に、開発者がシステムを変更する理由を伝えるための知識をよりよく提供するためのオプションの概要を見てみましょう。

1. ファイルシステム
   • 個々のパッケージは、任意のフォルダー、任意の場所に保存されます。
   • セキュリティはありません。ファイルは、事前の知識がなくても、ユーザーまたはプロセスによって変更できます。また、これを防ぐためのネイティブプロセスはありません。
   • 通常のバックアップスケジュールの一部ではありません。システムスナップショットは実行可能なバックアップではなく、修復不可能な損傷を引き起こす可能性のある誤った変更を防ぎません。
   • パッケージを手動で整理する必要があり、物理的な場所やドキュメントの外でパッケージをグループ化することはできません
   • 構成ファイルを使用して値をパラメーター化することを強制
2. SSISパッケージストア
   • デフォルトでは、パッケージは特定のフォルダー「C：\ Program Files\Microsoft SQL Server\<SQL Version Compiled>\DTS\Packages”。移動できます。
   • 限定的なセキュリティ。昇格した権限で変更できます
   • システムスナップショット以外のバックアップ戦略の一部ではありません（ここでも、有効なバックアップソリューションではありません）
   • フォルダの下でパッケージを整理できます
   • ロールを使用してSSISパッケージストアからパッケージへのアクセスを制限することはできません
3. SQLサーバー（msdb）
   • パッケージはmsdbに保存され、ファイル共有にエクスポートできます。
   • セキュリティはmsdbへのアクセスに関連付けられています。
   • システムmsdbは有効なバックアップソリューションの一部です。
   • AlwaysOnソリューションに追加できない
   • フォルダを使用して分類することができます
   • ロールを使用して、sysadminの使用を回避する2016以降の権限を管理できます。 統合サービスの役割（SSISサービス）-MS Docs
4. SSISDBカタログ
   • パッケージは、証明書で暗号化されたSSISDB内に排他的に格納されます
   • セキュリティは、個別の権限と役割によってさらに強化されます（上記のリンクを参照）。
   • SSISDBは有効なバックアップソリューションの一部です
   • SQL Server 2016以降では、AlwaysOn！のサポートが追加されました。 SQL Server 2016 HAシリーズパート2 – SSISおよび可用性グループ–ブログMicrosoft
   • パラメータ、環境変数を含む成熟した管理階層。
   • Visual Studioとの完全な統合を提供
   • SQLエージェントジョブは、構成ファイル参照または実際のパスワードを直接使用することはもうありません（とにかく誰もこれを行っていないことを願います）。SSMSからスクリプト化されません。

最終的には、組織にとってどのパスが有効かを決定できます。 SSISカタログはいくつかの方法の1つであるため、管理者にこの取り組みをサポートしてもらうことは、変更を加えるのに長い道のりとなります。配置のサンプルスキームについて説明した後、この投稿の残りの部分では、Visual Studioの管理とSSISカタログのヒントをいくつか取り上げます。

スキームの例は次のとおりです。

• すべての新しい取り組みでは、下位互換性のために[Visual Studio] 2017または2015とSQL Serverデータツールを使用します SQL Serverデータツール（SSDT）をダウンロード-docs.Microsoft.com）。 o VS 2019では、これをマーケットプレイスコンポーネントとして追加したことに注意してください）
• プロジェクトはコード管理フォルダー（GitHubフォルダー）に保存されるため、作業はバージョン管理されるか、DEV環境でSSISカタログを使用しますが、理想的にはGitHubリポジトリを使用します。
• パッケージコンポーネントは、最初にDev/Cert環境の各ノードにインストールされます。エンタープライズDBAは、これらのダウンロードを単一のファイル共有に収集して、クラスター化されたターゲットサーバーへのアクセス/転送を容易にし、それらが各ターゲットサーバー上にあることを確認します。

ボーナスセクション：

Visual Studioの管理のヒント：

1. パッケージは両方の展開バージョンに依存します（SQL ServerインスタンスのIntegration Servicesと一致する必要があります）

---（

• また、使用するコンポーネントに応じた32ビット/ 64ビット構成。

  2. パラメータを使用するには、「変数」ではなくパッケージの「パラメータ」またはプロジェクトパラメータを使用する必要があります。これらを使用して、使用する接続を環境的に制御します。

3. ターゲットの場所に接続して展開できます（SSISDBを使用する必要はありません）。

SSISDBカタログ管理のヒント：

1）ボタンをクリックするだけでバージョンを復元し、マイナスの変更を取り消したり、転送を元に戻すことができます！

2）SSMSからプロジェクトパラメータの管理、検証、バージョン管理を行うことができます。 VSは必要ありません。

• ここから環境パラメーターを構成します。

• SQL Serverエージェントジョブとは異なり、パスワードはSSISDBデータベース内で安全に保護されます。

例：

EXEC @ReturnCode = msdb.dbo.sp_add_jobstep @job_id=@jobId, @step_name=N'<name of step>', 
        @step_id=1, 
        @cmdexec_success_code=0, 
        @on_success_action=3, 
        @on_success_step_id=0, 
        @on_fail_action=2, 
        @on_fail_step_id=0, 
        @retry_attempts=0, 
        @retry_interval=0, 
        @os_run_priority=0, @subsystem=N'SSIS', 
        @command=N'/ISSERVER "\"\SSISDB\Replication\SSISDB_Replication\SSISDB_Replication.dtsx\"" /SERVER <ServerName> /ENVREFERENCE 3 /Par "\"$ServerOption::LOGGING_LEVEL(Int16)\"";1 /Par "\"$ServerOption::SYNCHRONIZED(Boolean)\"";True /CALLERINFO SQLAGENT /REPORTING E', 
        @database_name=N'master', 
        @flags=0

3）環境セットを選択した後、各SQL Serverエージェントジョブはこれらのパラメーターを使用します。

• パッケージソースSSISカタログを選択します。

• 変数の環境を設定します。

• ほとんどの場合、パラメーターは自動的に設定されます。

4）サーバーへのRDPを使用せずに、SSMS内で実際に問題が発生した箇所を確認します。

5）実際の統計を使用する実行間のパフォーマンスを確認してください！

何か不足していますか？これをコミュニティの回答にしてください。