パノラマ サイズとデザイン ガイド

パノラマ サイズとデザイン ガイド

398320
Created On 09/25/18 19:43 PM - Last Modified 09/05/23 19:10 PM


Resolution


パノラマ管理とロギングの概要

 

 

 

 

 

パノラマ ソリューションは、2 つの全体的な機能で構成されています: デバイスの管理とログ収集/レポート作成。これらの 2 つの主な機能の概要を簡単に従ってください。

 

デバイス管理:これには、構成管理と展開、パン OS およびコンテンツの更新の展開などのアクティビティが含まれます。

ログ収集: 1 つまたは複数のファイアウォールから1つのパノラマまたは分散ログ収集インフラストラクチャへのログの収集が含まれます。配置されたファイアウォールからログを収集、に加えてレポート生成できますに基づいて上に存在するローカルにパノラマ (例えば単一の M シリーズまたは VM アプライアンス) の分散ロギング インフラストラクチャかどうかデータをログに記録します。

 

パノラマ ソリューションは、管理インフラストラクチャのさまざまな物理的にこれらの関数を割り当てることによって設計に柔軟性を提供できます。たとえば: ファイアウォールが共存の専用ログ コレクターにそのログを転送中、VM パノラマからデバイス管理を実行可能性があります。

 

Graphic1.png

 

 

 

上記の例では、デバイス管理機能とレポートは、VM パノラマ アプライアンスで実行されます。3 ログ コレクター グループです。グループ A、2 つのログのコレクターが含まれている、3 つのスタンドアロン ファイアウォールからのログを受信します。グループ B から成っている 1 つのコレクターと高可用性 (HA) は、アクティブ/パッシブの構成に、ファイアウォールのペアからのログを受信します。グループ C は同様に、2 つのログのコレクターが含まれていて、ファイアウォールの 2 HA 組からログを受け取ります。任意の場所ではログのコレクターの数はいくつかの要因に依存しています。設計に関する考慮事項は以下で説明します。注: 任意のプラットフォームは、専用のマネージャーをすることができますが、のみ M シリーズは、専用のログ収集をすることができます。

 

 

ログ収集

 

管理対象デバイス

 

すべて現在パノラマ プラットフォームには、1000 個のデバイス管理の目的のための上限がありますが、パノラマ サイズ着信ログ率はすべての管理対象デバイスからになりますを理解するために重要です。手始めに、パノラマによって管理される合計ファイアウォール機器のインベントリを取る。

 

次のスプレッドシートを使用して、ログを格納する必要がありますお使いのデバイスのインベントリを作成します。

モデルパン OS (主要なブランチ #) 場所ログの平均速度を測定  
Ex: 5060   Ex: 6.1.0Ex: メイン データ センター  例: 2500 ログ/秒
    
    
    
    

 

  

ログの要件

 

このセクションは、適切サイズし、お客様の要件をサポートするためパノラマ ロギング インフラストラクチャを展開するために必要な情報を説明します。必要な総ストレージ容量と分散ログ コレクターを介してストレージを割り当てる方法を決定する 3 つの主な要因があります。これらの要因は次のとおりです。

  • ログ取り込み要件: これはパノラマ インフラストラクチャに 1 秒あたりに送信されるログの合計数です。
  • ログのストレージ要件: これは顧客を管理プラットフォームのログを保持する必要がある期間です。両方のポリシー ベースを含んでこれのため別の駆動要因と規制へのコンプライアンスの動機があります。
  • デバイスの場所: ファイアウォールの物理的な場所は、WAN 帯域幅等に基づいてリモートの場所で DLC アプライアンスを配置する決定を駆動できます。

 

これらの各要素は、以下のセクションで説明します。

 

ログ取り込みの要件

 

管理対象デバイスの集計ログ転送速度は、ディスクへの受信、処理、および書き込みよりも多くのログが定期的にパノラマに送信されるようにアヴォ id を設計するために理解する必要があります。次の表は、各ハードウェアプラットフォームがパノラマに転送できる1秒あたりのログの最大数を示し、soluti を設計するときに、顧客環境でパノラマに転送できるログの最大数を計算するときに使用できます。

 

         デバイス ログ転送

プラットフォーム 1 秒 (LPS) サポートされているログ 
PA 200250
PA 2201200
PA 500625
PA-820/85010,000
PA 3000 シリーズ10,000
PA-32207000
PA-325015,000
PA-326024000
PA-5050/60

10,000

PA-522030,000
PA-525055000
PA-5260テストする
PA-7050/708070,000
VM-50

1,250

VM-100/200

2,500

VM 300/1000 HV

8,000

VM 500

8,000

VM 700

10,000

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


パノラマのログ取り込み速度は、プラットフォームとモード (混在モードの詩ロガー モード) を使用によって影響されます。次の表は、異なるプラットフォームで使用できる、操作のモードでパノラマの摂取率を示します。  vm の横にある括弧内の数字は、vm に割り当てられた cpu とギガバイトの RAM の数を表します。

 

 

 

       パノラマ ログ摂取

プラットフォーム 混合専用 
VM (8/16)10,00018000
M-20010,00028000
M-50015,00030,000
M-60025,00050,000

 

上記の数値は、すべての最大値です。ライブ展開では、実際のログ率は一般的にサポートされている最大の一部です。実際のログ率の決定、お客様のトラフィック ミックスに大きく依存とスループットに縛られることはないです。たとえば、単一のオフロードされた SMB セッションは高スループットを示すが 1 つのトラフィックのログを生成するだけ。逆に、何千もの UDP DNS それぞれが別のトラフィックを生成するクエリのログから成る小さいスループットを持つことができます。サイズについては、1 秒あたりの接続数と 1 秒あたりのログとの間のおおよその相関を描画できます。

 

 

ログ率を決定する方法

新規のお客様:

  • 既存顧客のソースからの情報を活用します。多くの顧客は、Splunk、ArcSight、Qradar など場所に第三者ログ ソリューションを持っています。その既存のファイアウォール ソリューションから送信されるログの数は、これらのシステムから取り出すことが。このメソッドを使用して、一日のサードパーティ製のソリューションからログ数を取得、86,400 (1 日の秒数) で割ります。数日間平均を取得するこれを行います。通常ログ率 2 つの間に大きな差があるので、ビジネスや非営業日を含めるようにしてください。
  • 評価デバイスからのデータを使用します。この情報は、目的をサイジングするに非常に有用な出発点を提供できるし、顧客からの入力と同じデザインで他のサイトのデータを推定できます。  このメソッドには、数日間平均の収穫の利点があります。(説明付き) スクリプトがこのドキュメントに接続されているこの情報を見つけることができますを計算を支援します。使用するには、"ts_lps" という名前のファイルをダウンロードします。Zip ファイルを解凍し、手順については、README.txt を参照します。
  • 情報が使用できない場合は、参照ポイントとして上記デバイス ログの転送テーブルを使用します。これは、特定の顧客に対して少なくとも正確なメソッドになります。

既存の顧客:

    既存の顧客に彼らの既存のファイアウォールとログ コレクターから収集したデータを活用できます。

    • 単一のファイアウォールのログレートを確認するには、"D デバイス" という名前の添付ファイルをダウンロードし、zip ファイルを解凍して、手順について readme.txt ファイルを参照します。このパッケージは単一のファイアウォールを照会 (サンプルの数を選択できます) の時間の指定された期間とその期間の 1 秒あたりのログの平均数を与えます。少なくともこのスクリプトは、営業日に24時間連続して実行する必要があります。完全な週のスクリプトを実行すると、ネットワークの循環の減退と流れをキャプチャするのに役立ちます。お客様にログ収集が設定されていない場合、このプロセスは環境で各ファイアウォールに対して実行する必要があります。
  • お客様がログコレクター (またはログコレクター) を持っている場合は、"lc_lps" という名前の添付ファイルをダウンロードし、zip ファイルを解凍して readme.txt ファイルを参照してください。このパッケージは、ログコレクター MIB に照会して、受信ログのサンプルを取ります指定した期間のレート。

 

ログ記憶域の要件

 

ログ記憶域の要件に影響を与える要因

そのドライブ ログのストレージ要件のいくつかの要因があります。これらの要件のほとんどは、本質的に規制。お客様は、HIPAA、PCI、またはサーベンス Oxely のコンプライアンス要件を満たす必要があります。

 

 

 

考慮する必要があります他の政府と業界標準があります。さらに、いくつかの企業内部の要件があります。たとえば: 日分ログの数が元の管理プラットフォームを維持します。ログ記憶域ソリューションを設計するときお客様が対処、これらすべての要件を確認します。

 

フォーカスは、保存する必要があるログの日数の minumum 数になります。規制またはポリシーにより最大日数が必要な場合は、クォータ構成でログを保持する最大日数を設定できます。

 

必要な記憶域を計算します。

特定の顧客の要件に基づいて必要なストレージスペースを計算することはかなりまっすぐ進むプロセスですが、精度の高い学位を達成するときに労働集約的なことができます。PAN-OS 8.0 では、すべてのログの種類の集計サイズは500バイトです。この番号は、ログ自体だけでなく、関連付けられているインデックスの両方を占めています。脅威データベースは URL、野火の提出と同様に、脅威ログのデータ ソースとログ データをフィルター処理します。

    長期的なアーカイブのためにログ ソリューション私たちできないことに注意してください。  これらのケースでは、Syslog アーカイブ目的での転送をお勧めします。 

 

 

 

特定のログの種類のストレージ要件を決定する式です。

ストレージ要件の計算

 

例: 毎秒 1500 ログのログ速度でトラフィック ログの 30 日分を維持することができるユーザーします。

 

 保持 Calc の例 .png

 

 

 

 

上記の計算の結果は、詳細なログのみを占めています。デフォルトのクォータ設定では、詳細ログに使用可能なストレージの 60% を予約します。つまり、計算された数値は、購入する必要がある合計ストレージの60% を表します。必要なストレージの合計を計算するには、この番号を60に分割ます。

 

合計ストレージの例 .png

 

 

パノラマ8.0 以降の既定のログクォータは次のとおりです。

 

ログ タイプ% ストレージ
詳細なファイアウォールのログ

60

概要ファイアウォールのログ30
インフラストラクチャおよび監査ログ5
パロ ・ アルト ネットワーク プラットフォーム ログ.1
第 3 党の外部ログ.1

 

 

 添付のワークシートはパノラマの既定のクォータを考慮し、必要なストレージの合計容量を提供します。

 

 

 

ログ サービスの必要な記憶域を計算します。

 

ログ サービスを使用してログ収集をサイジングするに 3 つのケースがあります。 詳細なサイジングのガイダンスについては、ロギングサービスのサイズ変更ストレージを参照してください。

 

  1. パロ ・ アルト ネットワーク次世代ファイアウォールのログ収集
  2. GlobalProtect クラウド サービス モバイル ユーザーのログ収集
  3. GlobalProtect クラウド サービス リモート ・ オフィスのログ収集

 

 

パロアルトの次世代ファイアウォールのログ収集

上の前提ログ コレクターのサイズ変更の際、ログ サイジングのファイアウォール ログ サービスにログ記録のための方法論は同じです。唯一の違いは、ディスク上のログのサイズです。 ログサービスでは、脅威とトラフィックログの両方を1500バイトのサイズで計算できます。 

 

GlobalProtect クラウド サービス モバイル ユーザーのログ収集

ユーザー ログあたりの世代はその環境で実行されているワークロードと同様、両方のユーザーの種類に大きく依存します。 平均すると、1 TB のストレージをログ サービスには 5000 ユーザーの 30 日の保持を提供します。ログ サービスの利点は、ストレージを追加することが前提のコレクションを分散環境で従来のよりも行うにはるかに簡単です。これは、環境が平均よりもかなり忙しく場合、それは保存要件を満たすために必要な任意の記憶域を追加する簡単な問題を意味します。

 

GlobalProtect クラウド サービス リモート ・ オフィスのログ収集

GlobalProtect クラウド サービス (GPCS) リモート ・ オフィスの帯域幅に基づいて販売しています。ログ率がサンプル企業環境のログで、接続率とトラフィック ミックスに大きく左右される中、1 秒のスループットのメガビットあたり約 1.5 ログのレートで生成が行われます。添付サイズ変更作業シートこのレートを使用してログの推定平均率を提供するためにアカウント忙しい/オフ時間を考慮します。

 

 

 

 

 

LogDB の格納域の制限

 

記憶域のクォータをパン-OS バージョン 8.0 から簡素化。詳細ログと概要ログ各種類 (交通/脅威) に関係なく、独自のクォータがあります。

 

ログ タイプ

クォータ (%)

詳細なファイアウォールのログ60
概要ファイアウォールのログ30
インフラストラクチャおよび監査ログ5
パロ ・ アルト ネットワーク プラットフォーム ログ.1
第 3 党の外部ログ.1
合計95.2

 

 

 

デバイスの場所

ロギング インフラストラクチャにとって最後の設計の考慮事項は、ログオンにパノラマ台を基準にしてファイアウォールの場所です。デバイスは (例えば低速ネットワーク セグメントでパノラマから区切られた場合 T1/E1)、ファイアウォールを持つサイト上専用ログ コレクター (DLC) に配置をお勧めします。これはログ転送ログ コレクターに必要な場合を照会するパノラマを可能にしながら高速 LAN セグメントに限定することができます。リファレンスについては、次の表は、異なるログ レートでログ転送の帯域幅の使用を示します。これには、ファイアウォールにパノラマからパノラマ及び受信確認送信される両方のログが含まれます。7000 系と 5200 系の両方のログが転送時に圧縮されることに注意してください。

 

        ログの転送帯域幅

ログ レート (LP) 使用される帯域幅
13008 Mbps

8000

56 Mbps
1000064 Mbps
1600052.8 140.8 Mbps (96.8) 

 

 

ログの転送帯域幅 - 7000 と 5200 シリーズ

ログ レート (LP) 使用される帯域幅
1300.6 Mbps

8000

4 Mbps
100004.5 Mbps
160005-10 Mbps

 

 

 

 

 

デバイス管理

パノラマ展開するためのプラットフォームを選択するときに考慮するいくつかの要因があります。初期の要因があります。

  • 同時実行管理者の数は、サポートが必要なですか。
  • セキュリティ チームがアクセスする VMWare 仮想化インフラストラクチャは、顧客か
  • 顧客は二重化電源を要求するか。
  • 推定構成のサイズは何ですか。
  • デバイス ハンドルがコレクションにもログに記録ですか。

 

パノラマ仮想アプライアンス

このプラットフォームは、仮想 M-100 として動作し、同じログ摂取率を共有します。追加のリソースを追加すると、両方のスケールに仮想パノラマ アプライアンス管理機能と同様に、それの摂取率。パノラマの仮想アプライアンス 8.0 を実行するための最小要件は、8 の Vcpu と 16 GB vRAM です。

 

 

 

 

 

仮想アプライアンスを選択するときは?

  • お客様がセキュリティへのアクセスを持っている大型の VMWare インフラストラクチャ
  • 顧客専用のログ コレクターを使用して、混合モードになっていません。

仮想アプライアンスを選択する、しないときは?

  • サーバー チームとセキュリティ チームは別と共有したくないです。
  • お客様が仮想インフラストラクチャを持たない

 

M-100 ハードウェア プラットフォーム

このプラットフォームは、専用のハードウェアと同時 15 管理者まで処理することができます。混在モードでは、1 秒あたり 10,000-15,000 のログを摂取することが可能です。

M-100 を選択するときは?

  • お客様専用のプラットフォームを必要がありますが非常に価格に敏感
  • 顧客専用のログ コレクターを使用して、混在モードでは、VM のインフラを持っていません。

M-100 を選択する、しないときは?

  • 二重化電源が必要な場合
  • 以上 10 k/s またはログの保存に必要な 8 TB 以上との混合モード
  • 以上 15 の同時管理者には

 

M-500 ハードウェア プラットフォーム

このプラットフォームは、混在モードにある場合でも、最高ログ摂取率を持つ. リソースの可用性は、大規模な構成およびより多くの同時管理者 (15-30) を処理します。二重化電源を提供しています強力な成長のロードマップ。

M-500 を選択するときは?

  • 専用プラットフォームが必要なお客様で、大規模または成長の展開
  • お客様は、ログよりも 10 k/秒のデュアル モードを使用しています。
  • 未来へのお客様希望が、彼らの投資を証明
  • 顧客専用アプライアンスを必要がありますが 15 を超える同時管理者
  • 二重化電源装置が必要です。

M-500 を選択する、しないときは?

  • 最初の環境の VM には 48 TB 以上のログ ストレージを必要としない場合
  • 顧客は非常に価格に敏感

 

高可用性

このセクションは、高可用性の展開を計画するとき、設計に関する考慮事項を対処します。パノラマ高可用性はアクティブ/パッシブであり、両方のアプライアンスは、完全にライセンスを取得する必要があります。パノラマ ソリューションを展開する場合、高可用性を実現する 2 つの側面があります。これらの側面は、デバイスの管理とログします。2 つの側面が密接に関連してが、それぞれ固有の設計および構成要件。

 

デバイス管理 HA:パノラマデバイス (M シリーズまたは仮想アプライアンスのいずれか) が失われたときに、デバイス管理機能を保持する機能。

ログ記録の HA またはログの冗長性:パノラマデバイスが失われたときにファイアウォールログを保持する機能 (M シリーズのみ)。

 

デバイス管理ハ

高可用性設計のパノラマ ソリューションを展開すると、HA のピアが、物理的に離れた場所に多くの顧客を選択します。設計の観点からは、高可用性構成でパノラマ家電のペアを展開するときに考慮する 2 つの要因があります。これらの懸念は、ネットワーク レイテンシとスループット。

 

ネットワークの遅延

中間のネットワーク セグメントの遅延に影響 HA メンバー間のトラフィックを制御します。ハ関連タイマー顧客の展開の必要性を調整できます。最大値は 1000 ms をお勧めします。

  • プリエンプトホールド時間:プリエンプティブ・オプションが有効になっている場合、プリエンプト・ホールド時間は、パッシブ・デバイスがアクティブなロールを取るまでに待機する時間です。この場合、両方のデバイスとタイマーが「プライマリ」の優先順位を持つデバイスに適用されます。
  • プロモーションホールド時間:プロモーション保留タイマは、アクティブなローテを想定する前に、セカンダリデバイスが待機する間隔を指定します。この場合、プライマリ デバイスのエラーが発生しました、このタイマーは、セカンダリ デバイスに適用されます。
  • hello 間隔:このタイマは、ピアデバイスへの hello パケット間のミリ秒数を定義します。こんにちはパケットはピア デバイスが動作していることを確認に使用されます。
  • ハートビート間隔:このタイマは、ピアに送信される ICMP メッセージ間のミリ秒数を定義します。ハートビート パケットは、ピア デバイスが到達可能であることを確認に使用されます。

ネットワークの待ち時間およびハートビート間隔との関係

心臓の鼓動を HA ピアの到達可能性を確認するため、ハートビート間隔が HA メンバー間のリンクの遅延よりも高い設定必要があります。

 

ハ プリセット タイマー

お客様は、自分の環境に合わせて特別に、HA タイマーを設定できますが、パノラマには、顧客が使用できる構成済みのタイマーの 2 つのセットもあります。これらのプリセットは、顧客の展開の大半をカバーします。

 

推奨。

タイマ設定
優先権を保持時間1
こんにちは間隔8000
ハートビート間隔2000
モニター失敗の持続時間0
追加マスター ホールド アップ時間7000

 

積極的な。

タイマ設定     
優先権を保持時間500
こんにちは間隔8000
ハートビート間隔1000
モニター失敗の持続時間0
追加マスター ホールド アップ時間 5000

 

 

コンフィギュレーションの同期化

 

 

                                                                        ハ プロセスを同期

HA 構成を同期します。

 

 

ハ組のメンバーの 1 つの構成が変更されるとき、パノラマで HA 同期処理が行われます。アクティブ-プライマリで変更が行われ、コミットされると、構成を同期する必要があるアクティブ-セカンダリにメッセージを送信します。アクティブなセカンダリがそれの準備ができている確認を送り返します。アクティブなプライマリ アクティブ セカンダリ構成が送信されます。アクティブなセカンダリは変更をコミットするアクティブなプライマリ サーバーとキュー ジョブによって送信された構成をマージします。アクティブなプライマリ パノラマからメッセージ HA 同期の 3 分以内に完了する必要があります。主な関心事は、送信される構成のサイズと HA メンバーを別々 のネットワーク セグメントの実効スループットです。

 

 

ログの可用性

パノラマ高可用性ソリューションの他の部分は、ハードウェア障害が発生した場合のログの可用性を提供しています。(専用または混在モードで) ログ コレクターのインフラストラクチャを使用する場合、これを実現する方法を 2 つがあります。

 

ログ冗長性

パン OS 7.0 以降では、各ログを書き込むログ コレクター グループで 2 ログ収集する明示的なオプション。このオプションを有効にするには、デバイスはそれのプライマリ ログ コレクターに、同じグループ内の別のコレクターにログをレプリケートするそれのログを送信します。

 

 

ログ冗長性

ログの重複は、コレクターのログ ・ グループ内の特定のログの 2 つのコピーがあることを保証します。これはすべての回でログの可用性を保証する必要があるお客様に適したオプションです。考慮するべき事:

 

1。レプリケーションはログ コレクター グループ内でのみ起こる。

2。(各ログが 2 回書き込まれる) ので全体的に使用可能なストレージ スペースは半分になります。

3。全体的なログ摂取速度が最大 50% 低下します。

  

ログのバッファリング

ファイアウォールでは、ログを転送するパノラマプラットフォームからの受信確認が必要です。つまり、ファイアウォールのプライマリ ログ コレクターが使用できなくなった場合に、ログ バッファーし、するコレクターがオンラインに戻ったときに送信されます。バッファーのログに 2 つの方法があります。最初の方法は、個別のログ コレクター グループを構成する各ログ コレクターには。

 

ログのバッファリング

 

 

 

このような状況でログ コレクター 1 がダウンした場合ファイアウォール A ・ ファイアウォール B が各ログを保存のローカル ログ パーティションにコレクターの電源を再び入れたまで。現在のファイアウォールモデルのローカルログパーティションは次のとおりです。

 

モデルログ パーティション サイズ (GB) 
PA 2002.4
PA 22032
PA-800 シリーズ172
PA 3000 シリーズ   90
PA-3200 シリーズ125
Pa-5000 シリーズ88
PA-5200 シリーズ1800

 

2 番目のメソッドは、グループに複数のログ コレクターを配置することです。このシナリオでは、ファイアウォールを優先順位リストで構成して、プライマリ・ログ・コレクターがダウンした場合、リストの2番目のコレクタがログをバッファリングし、グループ内のすべてのコレクタがその時点でプライマリ・コレクタがダウンしていることを認識できるようにします。、新しいログがダウンコレクターに割り当てられるのを停止します。

 

次に示すアーキテクチャでファイアウォール A ・ ファイアウォール B が主に、バックアップとしてログ コレクター 2 ログ コレクター 1 に、ログを送信する構成されています。ログコレクタ1が到達不能になると、デバイスはログコレクタ2にログを送信します。コレクタ2は、コレクタ1に格納されるログを、コレクタ1を回転から引き出すことができるまでバッファする。

 

 

コレクター グループ - ログ冗長性がないです。

ログコレクターグループの設計に関する考慮事項

 

グループにログコレクターを構成する主な理由は、次の3つです。

 

  1. 特定のファイアウォール (またはファイアウォールのセット) に対して、単一のログコレクターによって提供される (スケール保持のための) よりも、ログの保存期間を大きくする必要があります。
  2. 特定のファイアウォールでは、1つのログコレクターによって提供されるよりも、より多くの取り込み容量が必要になります (スケールの取り込み)。
  3. ログの冗長性の要件。

 

ログコレクタグループの使用を検討する際には、設計段階で対処する必要があるいくつかの考慮事項があります。

 

  1. 利用可能なコレクター間での取り込みの拡大: 複数のデバイス転送優先順位リストを作成できます。これにより、コレクタグループ内の複数のコレクターが取り込みを処理できるようになります。たとえば、優先順位リスト1は、ファイアウォールとリストコレクタ1の半分をプライマリおよびコレクタ2としてセカンダリとして持ちます。優先順位リスト2は、セカンダリとしてプライマリおよびコレクタ1としてファイアウォールとリストコレクタ2の残りを持ちます。
  2. 待ち時間の問題: ログコレクターグループ内のコレクター間のネットワーク待ち時間は、パフォーマンスの重要な要素です。一般的な設計ガイドラインは、同じグループのメンバーであるすべてのコレクターを閉じておくことです。次の表は、冗長性を有効にして無効にすることで、さまざまな遅延測定で期待できることを示しています。この場合、「ログ遅延」は、高レイテンシの望ましくない結果である-ログは、パノラマに送信されるまで UI に表示されません。

 

 

インター LC レイテンシ (ミリ秒)ログレート冗長性が有効ログ遅延
5010K違います違います
1005K違います違います
10010K違いますうん
505Kうん違います
5010Kうんうん
1005Kうん違います
1503Kうん

違います

1505Kうん

うん

 

 

 

 サイズ変更ワークシートを使用

 

 

 必要な情報には、目的の保存期間と平均ログレートが含まれます。

 

ワークシートの例 .png

 

保存期間: ログを保持する必要がある日数。

平均ログレート: 測定または推定された集計ログレート。

冗長性が必要: ログの冗長性が必要な場合は、このチェックボックスをオンにします。

詳細ログ用のストレージ: 詳細ログの保存期間を満たすために必要なストレージ容量 (ギガバイト単位)。

必要なストレージの合計: 購入するストレージ (ギガバイト単位)。このアカウントは、defualt クォータ設定ですべてのログの種類を占めます。

 

 

使用事例

 

使用事例 1

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ユース ケース 2

 

ユース ケース 3

 

ユース ・ ケース 4

 

  コレクター グループ - ログ冗長性がないです。 



Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Clc8CAC&lang=ja&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language