Sizing

Prev Next

To decide which platform or platforms will host the solution and the size of the solutions requires the following:

  • The number of sites. For example how many branch offices will be included in the solution.
  • The number of users that will want access to the data, both globally and per site.
  • The physical size of the existng data.
  • The number of shares and the number of files.
  • The physical size of the data at the edge.

CTERA provides a sizing tool that can be used to determine some of the deployment requirements, based on the above information. You can also deploy a CTERA Edge Filer to run a discovery of the shares in the legacy file system that you will want to migrate.

When designing the CTERA environment, consider the following size limitations:

  • 10 billion files per portal.
  • 250 million files (or 250TB) per portal cloud folder.
  • 250 million files (or 250TB) per portal folder group.

If you are going to exceed these values, consider deploying more than one portal cluster.

Deciding On the Platform to Host the Deployment

The CTERA Portal and CTERA Edge Filers can be deployed in a cloud environment, AWS or Azure, or in an on-premises environment: ESXi, Hyper-V, KVM, Proxmox, and others.

A hybrid deployment is also possible.

Deploying an Edge Filer for Legacy Filesystem Discovery

Use CTERA Migrate to run a discovery job on the legacy file server to survey the current file server to discover which shares to migrate. The survey includes the current shares, their size, number of files, when modified, etc.

Video: Deploying an Edge Filer for Legacy Filesystem Discovery

Deploying the Edge Filer

To run a discovery job you need to install an edge filer. The edge filer does not need to be licensed and does not need a data disk.

Note

The following installation is for ESXi but you can also install the edge filer in AWS or Azure using their marketplace or on other platforms, such as Proxmox. Refer to the relevant platform documentation.

To install the CTERA Edge Filer using the vSphere Client:

  1. In the vSphere Client, create a virtual machine by deploying the OVA file received from CTERA support as an OVF template.
  2. In the wizard, browse to the CTERA Edge Filer ova file and select it.
  3. Click NEXT.
  4. Continue through the wizard leaving the default values unless required:
    • The compute resource.
    • The storage to run the CTERA Edge Filer.
    • The destination network that the CTERA Edge Filer will use.
  5. Review the configuration details and click FINISH.
    The CTERA Edge Filer is created.
  6. Depending on the edge filer license, change the RAM and CPU.
  7. Power on the virtual machine.
    Using DHCP, after a few seconds, the IP address to access the CTERA Edge Filer is displayed in the vSphere Client.
  8. Open any web browser.
  9. Enter the CTERA Edge Filer's IP address to navigate to the device.
    Note

    The URL to enter must be https and not http. That is, https://edge_filer_ip_address and not http://edge_filer_ip_address

    Your browser displays the Welcome to CTERA Edge Filer page.
    Image
  10. Enter migration for the user name and CTERAis#1 for the password fields.
  11. Click Create Account.
    The following message window is displayed.
    Image
  12. Click Cancel to close the wizard.
    The edge filer Main > Dashboard is displayed.
    Ignore the warnings and alerts.

Running the Legacy Filesystem Discovery

To run the discovery job:

  1. In the edge filer Dashboard page click Filer Server Migration.
    The File Server Migration Dashboard page is displayed.
    image.png
  2. Click + to create a new job.
    The Create Discovery Job wizard is displayed showing the Task Type step.
    Image
    The default job is a Discovery job. This job analyzes the file server that is being replaced to identify what data should be migrated.
  3. Click Next.
    The Connect step is displayed.
    Image
  4. Select the server type to connect to from the drop-down box:
    • Other
    • Azure StorSimple
    • HCP Gateway
    • Hitachi Data Ingestor
    • Isilon OneFS
    • Microsoft Azure Files
    • Nasuni Edge Appliance
    • NetApp ONTAP
    • NetAPP StorageGRID 11 (SMB)
    • NetAPP StorageGRID 9 (SMB)
    • Panzura Freedom Filer
    • Windows Server
      If the legacy file server is not in the list, select Other.
  5. Select the SMB protocol to use for the discovery.
  6. Enter the IP address or DNS name for the source file server.
  7. Enter an administrator user name and password to access the server.
    Notes

    The administrator used must have access to the files to migrate.

    For Microsoft Azure Files, the shares cannot be presented and have to be added manually. Expert Mode is automatically selected to enable specifying the shares in the next step. The Source value is the IP address of the storage account, the Username value is the name of the storage account and the Password value is the access key for the storage account and not for the file share.

  8. Click Next.
    The Select Shares step is displayed.
    Image
    The shares on the file server are displayed, and you can select the shares that you want to migrate.
    Note

    When Expert Mode is selected, the following window is displayed where you enter the shares to migrate.
    Image

  9. Select the shares to discover and click Next.
    Image
  10. Optionally, provide a different name for the job and any specific notes about the job.
  11. Click Create.

The discovery job runs and the results are displayed in the Dashboard.

The Dashboard After a Discovery Run

After analyzing the file server, the job completes and you get a report as well as a full analysis of each share in the filer server that you selected.
Image
Log files and discovery file lists generated by the migration are compressed if they are greater than 100MB.

Click the image.png icon to display the discovery report.

The Discovery Report

Clicking the image.png icon displays the discovery report:
Image

At the top of the report, the sum of the information for the migrated shares is displayed.

The first pane in the discovery report shows the list of shares with details of each share:

  • The number of folders in the selected shares.
  • The number of files in the selected shares.
  • The size of the selected shares.
  • The status of the migration for the selected shares.

The second pane in the discovery report has tabs showing the following:

  • Files – A pie chart with the sizes of the files in the selected shares.
  • Last Access – A bar chart showing when the files in the selected shares were last accessed.
    Image
  • Last Modified – A bar chart showing when the files in the selected shares were last modified.
    Image
  • File Types – The list of the file types in the selected shares.
    Image

You can display this information either By Count, for example, the number of each file type, or By Size, for example, the size of each file type.
Image

Optionally, click the image.png icon to download the discovery report as a .csv file.
Image

Note

Because there is no data disk, the breakdown of each share and any errot logs are not available. If you want a breakdown of the files in each share, you must have a data disk defined for the edge filer.

With a data disk, when Log Every File (Verbose Logging) is checked, optionally for each share, click the image.png icon to download the discovery report for that share as a .csv file.
Image

Any errors in the discovery job are written to a separate log, under /errorlog. Each share with an error has a separate log file. Clicking the image.png icon downloads the log file as a .csv file.

Click Details, or Image in the File Server Migration dashboard, to display the list of every time this job was run and rerun with the results of each run.
Image

Sizing the Portal

The portal requires storage for metadata for based on the pre-duplicated data: The data pool should be at least 1% of the portal global name space and the archive pool should be at least 2% of the portal global name space. The data pool is installed on every portal server. The archive pool is only installed on the primary and secondary portal servers.

A minimal production installation of CTERA Portal comprises of four 64-bit virtual machines: Two database servers (primary and secondary) and two application servers. The minimum two application servers are required for high availability and load balancing.

Additional application servers may be deployed for further load balancing.

Note

Either only one or only three application servers function as messaging servers.

Optionally, one or more preview servers can be deployed for document previews.

The following table details the requirements per CTERA Portal Server in a production environment.

Server Minimum Requirements Notes
Primary Database Server 8 vCPU, 32GB RAM, 200GB data pool (SSD), 200GB-400GB archive pool (Magnetic) The data pool should have at least 2000 IOPS and should be sized around 1% of the expected global file system size.
For ESXi environments, each server is deployed with a 250GB data pool.
The archive pool size should be around 2% of the expected global file system size.
Secondary, Replication, Database Server The replication database server must have the same configuration as the primary database server. –
Application Server 8 vCPUs, 32GB RAM, 100GB data pool (Magnetic) or, with the CTERA Messaging service:
8 vCPU, 32GB RAM, 250GB data pool (Magnetic)
An application server can handle up to 10,000 clients. When the number of expected clients will be near 10,000, 8 vCPUs and an additional 16GB RAM is recommended.
When the CTERA Messaging service is enabled, the data pool size should be a minimum of 250GB but a more accurate amount can be calculated as follows: data_pool = number_of_daily_audit_events × 4.3 where 4.3 is 3 retention days multiplied by 1.2 for the message size and then a 20%buffer.
CTERA recommends separate servers to use as messaging servers.
For ESXi environments, each server is deployed with a 250GB data pool.
Preview Server 8 vCPUs, 32GB RAM, 60GB data pool (SSD) –
Notes

All resources allocated to a server must be dedicated to that server and not shared with other servers. You must not run non-CTERA applications on any of the CTERA Portal servers.

CTERA recommends seeking guidance from CTERA support for a more accurate estimation of the required sizing.

Sizing the Edge Filer

The edge filer maximum storage is determined by the license.
The license dictates the maximum storage that can be used and the number of users.

License Maximum Storage Recommended Maximum Number of Users
EV16 16TB 500
EV32 32TB 1000
EV64 64TB 3000
EV128 128TB 5000
EV256 256TB 5000

The edge filer has a minimum storage requirement of 2TB or 20% of the maximum expected storage utilization, whichever is larger. The license is received from the portal when the edge filer connects to the portal.

The normal edge filer usage is memory and network intensive and not CPU intensive. The edge filer is installed with 4 vCPUs. Increasing the number of vCPUs allocated for the edge filer should take the usage in to account.

CTERA recommends the following vCPU and RAM minimum requirements:

  • The number vCPUs is the license number/4. For example, an edge filer with an EV32 license should start with 8 vCPUs.
  • The amount of RAM is the license number/2. For example, an edge filer with an EV32 license should start with 16GB RAM.

The above are minimum recommendations which should be increased dependent on the specific usage.