ほとんどのネットワーク自動化プログラムは、同じ場所で停滞してしまいます。コンピュート、ネットワーク設定、アプリケーションのデプロイはコードから実行されますが、DNS、DHCP、IPアドレス管理は依然としてチケット処理に依存したままです。 その理由は、自動化ツールチェーンにあることはめったにありません。その理由は、インフラストラクチャ・アズ・コード（IaC）が構成状態を管理する一方で、DDIは宣言されるのではなく、調整が必要な、動的で競合するインベントリを保持しているからです。このギャップを埋めるには、自動化のために構築されたDDIレイヤーが必要であり、それを実現するには3つの方法があります。BlueCat Micetroは、単一のAPIを通じて、すでに本番環境で稼働しているDNSおよびDHCPサーバーをオーケストレーションします。BlueCat Integrityは、DNS、DHCP、IPAMを1つのプラットフォームに統合し、すべてのインターフェース操作に対して文書化されたAPI相当の操作を提供します。BlueCat Horizonは、ホスト型コントロールプレーンからインフラ全体を調整し、プロトコルサービスはローカルで実行し続けます。
ネットワーク自動化プログラムがDDIの段階で停滞してしまうのは、DNS、DHCP、およびIPアドレス管理が、通常、自動化ツールチェーンの外にある、断片化された手動のレガシーツール上で依然として実行されているためです。 これらのシステムは、ネットワークアクティビティの限定的なビューしか提供せず、自動化がクエリできる信頼性の高い記録を保持しておらず、すべての変更を人間による手作業に戻すことを余儀なくされるため、他のすべての自動化ワークフローに共通する唯一の依存関係は、依然として手作業のままとなっています。
レガシーの DDI システムやプロセスは、自動化を単に遅くするだけでなく、安全性を損なう死角を生み出します。ツールが断片化していると、IT スタッフの時間の最大 30% が日常的な運用に費やされてしまいます。また、この断片化により、本番環境に反映される前に競合する変更を捕捉できる一元的なビューが存在しないため、サービス停止のリスクが高まります。 そのような状況の上に構築された自動化は、死角を解決するどころか、それを引き継いでしまうことになります。
DDIの統合は、単なるインターフェースだけでなく、業務の経済性そのものを変えます。レガシーなDDI管理から統合プラットフォームに移行した組織では、問題解決が75％高速化し、DDI運用に費やす時間が86.8％削減されたほか、DNS関連のサービス停止も解消されたと報告されています。 これらのメリットは、自動化が実際に依存する3つの特性、すなわち完全な可視性と制御、エンドツーエンドのプロセス自動化、そしてインフラストラクチャの信頼性から生まれています。
レガシーなDDI管理から統合プラットフォームへ移行した組織では、DDI運用に費やす時間が86.8％削減され、問題解決が75％高速化したと報告されています。
Read article
Learn with BlueCat how visibility and control, process automation, and infrastructure reliability offer three reasons to adopt Unified DDI.
Ansible、Terraform、および類似のツールは、DNSやIPの変更を実行することはできますが、アドレス空間の正式な記録システムとしては機能しません。 Infrastructure-as-codeは望ましい構成状態を宣言する一方、DDIはチームや環境をまたがる、動的で有限かつ競合するインベントリを調整しなければなりません。そのインベントリを保持し、APIを通じて公開するプラットフォームがなければ、自動化は、空き状態であることを確認できないアドレスを宣言することになってしまいます。
実用上の限界は、まずスケールにおいて、次にカバレッジにおいて現れます。 動的なクラウド環境全体で毎日数千件の DNS 変更を管理する組織には、パイプラインごとではなく、一貫して適用される自動化された競合解決とポリシーの強制が必要です。汎用ツールには、アドレスプール、競合、またはポリシーの境界という概念がネイティブには存在しないため、各パイプラインがこれらのルールを再実装することになり、各実装が互いにばらつきが生じてしまいます。
2つ目の制限は、DDIプラットフォームそのものです。多くのレガシーDDIシステムには、現代の自動化ワークフローに必要なAPI機能が欠けており、つまり制約は自動化ツールそのものではないということです。 プラットフォームがそのインターフェースで可能な機能の一部しか公開していない場合、自動化はその境界で止まり、手動による例外処理が恒久的なものとなってしまいます。「セキュリティ・バイ・デザイン」、クラウド統合、およびAPIのプログラム可能性こそが、DDIレイヤーが自動化の実践に参画できるか、それとも単にその傍観者に留まるかを決定づける要素なのです。
Read article
Learn with BlueCat how security by design, cloud integration, and API programmability offer three technical reasons to adopt Unified DDI.
実践的なアプローチは3つあります。 すでに本番環境で稼働しているDNSおよびDHCPサーバーを、単一のコントロールプレーンの背後でオーケストレーションし、それらをその場に残したままにします。 DNS、DHCP、IPAMを1つのAPIファースト・プラットフォームに統合し、すべてのインターフェース操作に対して文書化されたAPI相当物を用意します。あるいは、プロトコル・サービスがローカルで実行され続ける一方で、ホスト型コントロールプレーンから環境全体を調整することも可能です。これら3つのアプローチはいずれも自動化可能なDDIレイヤーを構築しますが、既存のインフラストラクチャへの影響や、プラットフォームのどの部分を自社で運用するかという点で異なります。
オーケストレーションは、既存のサーバーを維持しなければならない環境に適しています。コントロールプレーンは、Microsoft、BIND、Kea、およびクラウドサービスの上に位置し、それらすべてに対して単一のAPIを提供します。また、基盤となるインフラストラクチャには手を加えないため、移行作業を行うことなく自動化パターンを確立できます。 統合は、もともと標準化が進められている環境に適しています。断片化したツールを単一のプラットフォームに置き換えることで、変換レイヤーを完全に排除し、移行を伴うものの、完全なプログラム対応範囲を持つ単一の信頼できるレコードを自動化に提供します。
3つ目のアプローチは、コントロールプレーンの機能そのものではなく、誰がそれを運用するかという点に変化をもたらします。ホスト型コントロールプレーンは、ポリシー、ID管理、レポート作成、自動化を一元化する一方で、DNSとDHCPは各環境内でローカルに解決し続けます。これは、重心がクラウドに移行した環境や、別のプラットフォームを運用する余力のないチームに適しています。 これら3つのアプローチに共通するのは、その根底にある要件、すなわち、DDIをDevOpsパイプライン、セキュリティツール、ITSMプラットフォーム、およびインフラストラクチャ・アズ・コード（IaC）の実践に接続する包括的なAPIです。これにより、エンドツーエンドのワークフローはデータのコピーではなく、権威あるデータに基づいて実行されます。
Read article
Unify DNS, DHCP, and IPAM (DDI) to boost visibility, automation, and security. Explore nine reasons to modernize DDI and streamline network operations.
その道筋は、今日すぐに確認できる2つの要素によって決まります。それは、DDIチームの管理外にあるパブリッククラウド上で既に稼働しているインフラの割合と、現在のプラットフォームのAPIカバレッジがどれほど完全であるか、という2点です。 クラウドアカウント間の断片化は、調整を行うコントロールプレーンの必要性を示唆しています。API以上の機能を備えたインターフェースを持つプラットフォームは、統合への道筋を示しています。機能はするがプログラムからアクセスできない環境は、オーケストレーションの必要性を示唆しています。
まずはクラウドのポスチャーから始めましょう。通常、それはすでに決定済みだからです。333人のITプロフェッショナルを対象としたEMAの調査によると、DDIチームの44％は、パブリッククラウドにおけるDDIの実装や管理に対して十分な影響力を持っていないと考えており、その影響力を欠いているチームほど、DDI戦略が失敗に終わったと報告する傾向が強いことがわかりました。 企業の79％は、すでにオンプレミスのIPアドレス管理をクラウド環境に統合しており、マルチクラウド環境を運用する組織では、その傾向がさらに顕著です。
次に、APIのカバレッジを確認してください。これはデータ上、最も有力な予測因子だからです。組織の89％がDDIをネットワーク自動化の「真実の源」として扱っており、83％がAPIを備えたDDIソリューションを導入していますが、それらに完全に満足しているのは44％未満にとどまっています。 この満足度のギャップは、成功度と密接に関連しています。DDI戦略が「非常に成功している」組織の70％が自社のAPIに完全に満足しているのに対し、戦略が「苦戦している」組織ではその割合は17％にとどまっています。インターフェースにアクションが存在しても、それに相当するAPIが文書化されていない場合、自動化はその境界で停止してしまいます。
DDI戦略が極めて成功している組織の70％が、自社のDDI APIに完全に満足しているのに対し、戦略が苦戦している組織ではその割合は17％にとどまっています。
Read article
Only 40% of enterprises believe they are fully successful with their DDI solution. Learn how to find greater success with new research from EMA and BlueCat.
オーケストレーションにより、すでに稼働しているDNSおよびDHCPサーバーの上にコントロールプレーンが配置され、それらすべてに対して単一のAPIが提供されます。 Microsoft、BIND、Kea、Cisco Meraki、およびクラウドベースのサービスは、これまで通り動作し続けますが、アドレス空間、レコード、およびポリシーは一元的に管理されます。これにより、プラットフォームごとに1つのワークフローを用意するのではなく、1つの自動化ワークフローですべてのバックエンドを網羅できるようになります。これは、汎用的な「Infrastructure-as-Code」が抱える具体的な課題を解消するものです。
BlueCat Micetro は、非破壊的なオーバーレイとしてこの役割を果たし、REST、SOAP、JSON-RPC アクセス、およびワークフローを構築するための Ansible モジュールを備えた単一の Web インターフェースを通じて、既存の DNS、DHCP、IPAM インフラストラクチャを統合およびオーケストレーションします。 基盤となるサーバーには手を加えないため、既存の運用モデルや投資はそのまま維持され、チームが最初の稼働パイプラインを構築する際に移行作業を挟むことなく、自動化パターンを確立することができます。
ガバナンスの側面は、API と同じくらい重要です。 一貫した監督なしに複数の管理者が DNS の変更を行うことは、よくある失敗例です。承認ワークフロー、ロールベースのアクセス、詳細な変更追跡によって、制御を損なうことなく自動化を実行することができます。レガシーな Microsoft DNS を近代化する環境では、MDDS アプライアンス、強化されたロギング、およびフェイルオーバー機能により、カットオーバーではなく段階的な移行パスが提供されます。
Read article
BlueCat Micetro is an easy, intuitive DDI orchestration solution that overlays your existing DNS, DHCP, and IPAM services to provide centralized visibility…
Read article
With Micetro, integrate, orchestrate, and automate your current DNS, DHCP, and IPAM network infrastructure via a single web interface.
統合により、変換レイヤーが排除されます。 1 つのプラットフォームが DNS、DHCP、IPAM を単一の権威あるレコードとして保持しており、インターフェースで利用可能なすべてのアクションは、文書化された API コールとして利用可能です。そのため、自動化の及ばない機能は一切ありません。 これは、自動化が DDI 自体を超えてセキュリティツール、可観測性、ITSM へと拡張する必要がある場合に最も重要になります。なぜなら、API の境界が、相関付け可能な範囲の境界となるからです。
BlueCat Integrityは、主張ではなく構造的な観点からカバレッジの問題に答えています。Integrity Xは、顧客に公開しているのと同じREST v2 API上で独自のインターフェースを実行します。このAPIはOpenAPIで定義され、Swaggerで閲覧可能であるため、手作業は自動化を回避するための競合経路ではなく、自動化のための仕様となります。 一元化されたDNS、DHCP、およびIP管理には、ポリシー主導のガバナンス、ロールベースのアクセス制御、コンプライアンス監査、および自動化された変更追跡機能がすでに組み込まれています。
その到達範囲はDDIの枠を超えています。Integrityは、LiveActionのネットワーク可観測性ツールと連携するように設計されており、両方を運用しているチームは、どちらか一方だけを運用する場合よりも作業が容易であると感じています。これは、どちらのプラットフォームも、もう一方からアクセスできないデータを保持することがないためです。 これこそが、「APIファースト」という主張に対する実用的な検証です。つまり、DDIベンダーが所有していないシステムから、そのプラットフォームのデータにアクセスできるかどうかということです。
Integrity X インターフェースでのすべてのアクションは、文書化された本物の REST v2 API 呼び出しとして実行されるため、自動化の範囲外となるインターフェース機能は一切ありません。
Read article
Discover API-first DDI with Integrity X by using REST v2 to automate DNS, DHCP, and IPAM for scalable, secure network operations.
Read article
Shift to proactive, intelligent network operations when you combine a DDI foundation with network performance monitoring solutions.
Read article
Tame network complexity with Integrity's full-stack DDI management platform and get visibility and control over your DNS, DHCP, and IPAM.
ホスト型コントロールプレーンは、資産が複数のクラウドや環境に分散しており、機能よりも調整が重要な制約となっている場合に適しています。 ポリシー、ID、レポート、自動化は一元化される一方、DNS および DHCP はローカルで実行され続けるため、プロトコルサービスや大容量のテレメトリを、それらを生成する環境から移動させることなく、一貫性を確保することができます。
BlueCat Horizonは、DDIおよびLiveActionの買収により獲得したネットワーク可観測性ソリューションにまたがる一連のSaaSベースのプラットフォームサービスとして、そのコントロールプレーンを提供します。これは、BlueCat製品全体にわたって共有APIゲートウェイ、認証、認証情報の処理、インターフェースの一貫性、および一元化されたAI分析を提供するものであり、これにより、ポートフォリオ内の各部分で個別に正しく機能するだけでなく、ポートフォリオ全体で一貫性のある自動化が実現されます。 EMAは、DDIと可観測性の統合を、組織がネットワークサービスを作成・利用する方法における戦略的転換であると位置付けています。
制御の一元化は、実行の一元化とは異なります。制御プレーン、AI機能、およびオーケストレーションロジックはクラウド上で実行される一方、プロトコルサービスや大容量のテレメトリデータはオンプレミス、あるいは顧客自身のクラウド環境に残されます。 この分離により、これまで不可能だった製品横断的な自動化が可能になります。具体的には、サービスの場所や重要度に関するDDIデータによるインシデントワークフローの充実、DNSトラフィックの迂回を促進するリアルタイムのパフォーマンス分析、そして自動封じ込めをトリガーするDNSベースの脅威検出などが挙げられます。
Read article
EMA evaluates BlueCat Horizon, highlighting unified DDI and observability, SaaS control architecture, and AI-driven integration benefits.
Read article
BlueCat Horizon is a SaaS-first Intelligent NetOps platform unifying DNS, DHCP, IPAM, security, and observability to automate modern network operations AI
道筋は制約に従います。サーバーを維持する必要がある場合は、それらをオーケストレーションします。プラットフォームの置き換えがすでに進行中の場合は、APIを完全に網羅した単一のプラットフォームに統合します。インフラが複数のクラウドに分散しており、一貫性が問題となる場合は、ホスト型コントロールプレーンから調整を行います。決定までまだ数ヶ月ある場合は、評価で適切な項目を検証できるよう、今すぐ要件を定義しておきましょう。
これらの回答は、既存のネットワーク自動化の実践をDNS、DHCP、およびIPアドレス管理へと拡張しようとしているチームから寄せられるよくある質問に対処するものです。
まだご質問がありますか？
BlueCatの担当者から具体的な回答を得ましょう。
