>
    Deploy the HSF Cluster
    Focus
    Download PDF
    Focus
    1. Home
    2. CN-Series
    3. CN-Series HSF
    4. Deploy the HSF Cluster
    Download PDF
    CN-Series

    Deploy the HSF Cluster

    Table of Contents

    Deploy the HSF Cluster

    Where Can I Use This?What Do I Need?
    • CN-Series HSF Firewall deployment
    • CN-Series 11.0.x or above Container Images
    • Panorama running PAN-OS 11.0.x or above version
    After ensuring that the prerequisites to deploy the CN-Series firewall as an HSF are met, navigate to KubernetesDeployments and click Add.
    You will need to configure the following tabs to deploy the HSF cluster.

    General

    Enter the following details in the General tab section of the Deployments pop-up.
    1. CN-Series Cluster Name—Name for the CN Series HSF.
    2. (Optional)Description—A text string to describe the HSF cluster.
    3. Kubernetes Cluster—A list of entries for clusters are created under the Setup section of the plugin. Choose the relevant cluster you created from the drop-down.
      The Kubernetes cluster will be displayed only if the details are committed and are valid for deployments.
    4. CN-Series Cluster Name—Name for the CN Series HSF.

    Node Data

    Enter the following details in the Node Data tab section of the Deployments pop-up.
    1. Namespace—Namespace in the existing Kubernetes cluster where the CN-Series HSF will be deployed.
    2. Node Info— Node pool labels are used to deploy each type of CN pod. You need to specify the CPU, Memory and Desired Pods for each of the pod types based on the availability on the nodes. The Labels and the Label value pairs are prerequisite values to exist on the node and you have to add the same key value pair used to label the nodes.
    3. Interfaces—Interface names for CN-DB, NGFW, CN-GW pods need to be added. Each Interface requires specific net-attach-def to be applied on the Kubernetes cluster. The plugin will name Ethernet x/1 and Ethernet x/2 by default. If you change the interface names for Ethernet x/1 and Ethernet x/2, then you will need to make the change in the network attachments section also. For the CN-GW pod, you can add up to 12 interfaces excluding CI and TI interfaces.
      The Kubernetes cluster will be displayed only if the details are committed and are valid for deployments.
    4. CN-Series Cluster Name—Name for the CN Series HSF.

    Image & Storage

    Enter the following details in the Image & Storage tab section of the Deployments pop-up.
    1. Image—You need to store the images either in the local or AWS repository and this cannot be validated by Panorama. However, Kubernetes cluster has connectivity to the repositories where the images are stored.
      1. CN-MGMT Image: The complete URI from the repository where the image is to be accessed by the Kubernetes environment for deploying the CN-MGMT pod.
      2. CN-MGMT INIT Image: The init image needed for CN- MGMT pod.
      3. CN-NGFW Image: The complete URI from the repository where the image is to be accessed by the Kubernetes environment for deploying CN-NGFW pod.
    2. Storage—If you would like to configure exclusive storage, click Dynamic in the Storage section for EKS environment and Static or Dynamic for Openshift environments and the plugin will configure the cloud storage. If you have chosen Static then you need to enter the Storage Key Values, Worker Nodelabel Key and Worker Nodelabel Value. You also need to enter the Path where the storage is mounted.
      You must add a valid non-default storage class in the namespace of the kubernetes environment. Else, if dynamic storage option is selected and no storage class name is provided, then the default storage class present in the namespace will be selected.
    3. Certificates—This is the Device certificate information to Enable or Disable information such as licensing and if enabled, you will need to provide the PIN ID and PIN VALUE.

    CN Configuration

    Enter the following details in the CN Configuration tab section of the Deployments pop-up:.
    1. Primary Panorama IP—Displays values of the public and private IP addresses of the Panorama on which the plugin is installed.
    2. Secondary Panorama IP—Displays values of the public and private IP addresses of the secondary Panorama (in case of HA) on which the plugin is installed.
    3. Device Group—You need to create a DG before configuring the deployment as mentioned in the prerequisite section. The Device Group dropdown lists all the DGs on the current Panorama and you need to choose a valid DG. The CN-MGMT pod will be registered under this DG. For steps to create a Device Group, see Step 5 of Prepare Panorama for CN-Series HSF Deployment.
    4. Template—You need to create a template (variable_template) for CN-GW specific details, before configuring the deployment as mentioned in the prerequisite section. The Template drop-down lists all the templates on the current Panorama. You need to choose a template suitable for your current deployment. After HSF deployment, this template will be added to a template stack by the plugin along with a K8S-CNF-Clustering-Readonly template which handles the basic configuration for CN-DB and CN-NGFW pods. It also configures the CI and TI links on the CN-GW pod. The CN-MGMT pod gets configurations from the template stack. For steps to create the variable template, see Step 6 of Prepare Panorama for CN-Series HSF Deployment.
    5. Log Collector Group (LCG)—This drop-down lists all the Log Collector Groups on the current Panorama and a suitable LCG needs to be chosen. It also configures the CI and TI links of the CN-GW pod. For steps to create LCG, see Step 7 of Prepare Panorama for CN-Series HSF Deployment.
    6. Jumbo Frame—The Jumbo Frame dropdown lists values - Enable, Disable, and AutoDetect. This configuration is applicable for all the pods in the CN-Series HSF.
    7. 5G Enabled—This is a radio button with Enable and Disable options and refers to the GTP configuration needed on the CN-Series HSF.
      You need to handle further settings needed on the template in the variable_template file.
    8. DPDK—This is a radio button with Enable and Disable options. If the underlying resources do not support DPDK, then by default the CN-Series HSF will be defaulted to packetmmap.
      On EKS, If you wish to use DPDK, you need to have an AMI with DPDK drivers configured on it. For more information, see Set up DPDK on AWS EKS.
      To enable DPDK on Openshift, you need to enable huge pages on the worker nodes. For more information see configuring hugepages.
      You will also need to enable VFIO PCI driver on worker nodes.
      modprobe vfio-pci echo 1 > /sys/module/vfio/parameters/enable_unsafe_noiommu_mode
    9. CPU Pinning—Choose to Enable or Disable CPU Pinning.
    10. Numa Enabled—Provide the Node number for NUMA.
    11. CPU Pinning Base—Provide the CPU number from where you wish to start cpu pinning of forwarding processes and skip the lower numbered CPUs.

    Auto-Scaling

    Enter the following details in the Auto-Scaling tab section of the Deployments pop-up.
    1. Enter the Autoscaling Metric, Scale In Threshold and Scale Out Threshold in the Autoscaling section.
    2. Click OK to commit the deployment.
      The following are the supported metrics for Autoscaling.
      • dataplanecpuutilizationpct
      • dataplanepacketbufferutilization
      • pansessionactive
      • pansessionutilization
      • pansessionsslproxyutilization
      • panthroughput
      • panpacketrate
      • panconnectionspersecond
    After you have entered all the configuration details, the Deployments tab displays the details of a single deployment that is stored. Click Commit to proceed with the deployment. After completion of commit, the plugin displays the Deploy button. Click the Deploy button to deploy the CN-Series HSF.
    After the CN-Series HSF deployment, the cluster creates a template stack, <cluster-name>-ts with K8S-CNF-Clustering-Readonly template and the variable template you created in Step 6 of Prepare Panorama for CN-Series HSF Deployment.
    The Device Group you referenced during the HSF deployment configuration (created in Step 5 of Prepare Panorama for CN-Series HSF Deployment) and the Template Stack created automatically after the HSF deployment is bootstrapped to the CN-MGMT pod. When the CN-MGMT pod connects to Panorama, the Device Group and Template Stack automatically gets associated with the HSF name.
    HSF information for CN-DB, CN-GW, and CN-NGFW pods are auto-populated when they are active. When these pods are up and running, the CN-MGMT pod sends details like CI IP address, pod details, device ID, and software version to Panorama.
    For Panorama High Availability (HA), the CN-MGMT pod sends updates to both active and passive Panoramas.

    © 2024 Palo Alto Networks, Inc. All rights reserved.