Skip to main content
BlueXP edge caching

Before you begin to deploy BlueXP edge caching

Contributors netapp-tonacki netapp-bcammett netapp-rlithman
PDFs

There are many requirements you need to be aware of before you begin to deploy BlueXP edge caching in the cloud and in your remote offices.

BlueXP edge caching Core design considerations

Depending on your requirements, you may need to deploy one or multiple BlueXP edge caching Core instances to create the BlueXP edge caching Fabric. The Core instance is designed to direct the flow of traffic between your distributed BlueXP edge caching Edge instances and the data center file server resources, for example, file shares, folders, and files.

When you are designing your BlueXP edge caching deployment you need to determine what's right for your environment in terms of scale, availability of resources, and in terms of redundancy. The BlueXP edge caching Core can be deployed in the following ways:

  • Stand-alone instance

  • Load Distributed design (Cold Standby)

See Sizing guidelines to understand the maximum number of Edge instances and total users that each configuration can support:

Consult your NetApp Solutions Engineer to discuss the best options for your enterprise deployment.

Sizing guidelines

There are a few sizing guideline ratios that you need to keep in mind when configuring the initial system. You should revisit these ratios after some usage history has accumulated to make sure you are using the system optimally. These include:

  • Edges/Core ratio

  • Distributed users/Edge ratio

  • Distributed users/Core ratio

Number of Edge Instances per Core Instance

Our guidelines recommend up to 10 Edge instances per BlueXP edge caching Core instance, with a maximum of 20 Edges per BlueXP edge caching Core instance. This is dependent to a significant degree upon the type and mean file size of the most common workload. In some cases, with more common workloads you can add more Edge instances per Core, but in these cases you should contact your account representative to determine how to correctly size the number of Edge and Core instances depending on the types and sizes of the file sets.

Note You can leverage multiple BlueXP edge caching Edge and Core instances simultaneously to scale out your infrastructure depending on the requirements.

Number of concurrent users per Edge instance

The BlueXP edge caching Edge handles the heavy lifting in terms of caching algorithms and file-level differencing. A single Edge instance can serve up to 500 users per dedicated physical Edge instance, and up to 300 users for dedicated virtual deployments. This is dependent to a significant degree upon the type and mean file size of the most common workload. For larger collaborative file types, guide towards 50% of the maximum users per BlueXP edge caching Edge lower boundary (depending on physical or virtual deployment). For more common Office items with a mean file size <1MB, guide towards the 100% users per Edge upper boundary (depending on physical or virtual deployment).

Note The BlueXP edge caching Edge detects whether it is running on a virtual or physical instance and it will limit the number of SMB connections to the local virtual file share to the maximum of 300 or 500 concurrent connections.

Number of concurrent users per Core instance

The BlueXP edge caching Core instance is extremely scalable, with a recommended concurrent user count of 3,000 users per Core. This is dependent to a significant degree upon the type and mean file size of the most common workload.

Consult your NetApp Solutions Engineer to discuss the best options for your enterprise deployment.

Prerequisites

The prerequisites described in this section are for the components installed in the cloud: the BlueXP edge caching Management Server and the BlueXP edge caching Core.

The BlueXP edge caching Edge prerequisites are described link:download-gfc-resources.html#bluexp-edge caching-edge-requirements[here].

Storage platform (volumes)

The back-end storage platform - in this case, your deployed Cloud Volumes ONTAP instance - should present SMB file shares. Any shares that will be exposed through BlueXP edge caching must allow the "Everyone" group Full Control at the share level, while restricting permissions through NTFS permissions.

If you have not set up at least one SMB file share on the Cloud Volumes ONTAP instance, then you need to have the following information ready so you can configure this information during installation:

  • Active Directory domain name, name server IP address, Active Directory admin credentials.

  • The name and size of the volume you want to create, the name of the aggregate on which the volume will be created, and the share name.

We recommend that the volume is large enough to accommodate the total data set for the application along with the ability to scale accordingly as the data set grows. If you have multiple aggregates in the working environment, see Managing existing aggregates to determine which aggregate has the most available space for the new volume.

BlueXP edge caching Management Server

The BlueXP edge caching Management Server requires external access over HTTPS (TCP port 443) to connect to the cloud provider subscription service and to access these URLs:

  • https://gfcproxyforcm-prod.azurewebsites.net/

  • https://rest.zuora.com/v1/subscriptions/

  • https://rest.zuora.com/oauth/token

  • https://talonazuremicroservices.azurewebsites.net

  • https://talonlicensing.table.core.windows.net

This port must be excluded from any WAN optimization devices or firewall restriction policies for the BlueXP edge caching software to operate properly.

The BlueXP edge caching Management Server also requires a unique (geographical) NetBIOS name for the instance (such as GFC-MS1).

Note One Management Server can support multiple BlueXP edge caching Core instances deployed in different working environments. When deployed from BlueXP, each working environment has its own separate backend storage and would not contain the same data.

BlueXP edge caching Core

The BlueXP edge caching Core listens on TCP port range 6618-6630. Depending on your firewall or Network Security Group (NSG) configuration you may need to explicitly allow access to these ports through Inbound Port Rules. Also, these ports must be excluded from any WAN optimization devices or firewall restriction policies for the BlueXP edge caching software to operate properly.

The BlueXP edge caching Core requirements are:

  • A unique (geographical) NetBIOS name for the instance (such as GFC-CORE1)

  • Active Directory domain name

    • Instances should be joined to your Active Directory domain.

    • Instances should be managed in a BlueXP edge caching specific Organizational Unit (OU) and excluded from inherited company GPOs.

  • Service account. The services on the Core run as a specific domain user account. This account, also known as the Service Account, must have the following privileges on each of the SMB servers that will be associated with the BlueXP edge caching Core instance:

    • The provisioned Service Account must be a domain user.

      Depending on the level of restrictions and GPOs in the network environment, this account might require domain admin privileges.

    • It must have "Run as a Service" privileges.

    • The password should be set to "Never Expire".

    • The account option "User Must Change Password at Next Logon" should be DISABLED (unchecked).

    • It must be a member of the back-end file server Built-in Backup Operators group (this is automatically enabled when deployed through BlueXP).

License Management Server

  • The BlueXP edge caching License Management Server (LMS) should be configured on a Microsoft Windows Server 2016 Standard or Datacenter edition or Windows Server 2019 Standard or Datacenter edition, preferably on the BlueXP edge caching Core instance in the datacenter or cloud.

  • If you require a separate BlueXP edge caching LMS instance, you need to install the latest BlueXP edge caching software installation package on a pristine Microsoft Windows Server instance.

  • The LMS instance needs to be able to connect to the subscription service (public internet) using HTTPS (TCP port 443).

  • The Core and Edge instances need to connect to the LMS instance using HTTPS (TCP port 443).

Networking (External Access)

The BlueXP edge caching LMS requires external access over HTTPS (TCP port 443) to the following URLs.

  • If you are using GFC subscription-based licensing:

    • https://rest.zuora.com/v1/subscriptions/<subscription-no>

    • https://rest.zuora.com/oauth/token

  • If you are using NetApp NSS-based licensing:

    • https://login.netapp.com

    • https://login.netapp.com/ms_oauth/oauth2/endpoints

    • https://login.netapp.com/ms_oauth/oauth2/endpoints/oauthservice/tokens

  • If you are using NetApp legacy-based licensing:

    • https://talonazuremicroservices.azurewebsites.net

    • https://talonlicensing.table.core.windows.net

Networking

  • Firewall: TCP ports should be allowed between BlueXP edge caching Edge and Core instances.

  • BlueXP edge caching TCP Ports: 443 (HTTPS), 6618-6630.

  • Network optimization devices (such as Riverbed Steelhead) must be configured to pass-thru BlueXP edge caching specific ports (TCP 6618-6630).