Versions Compared

Version Old Version 3 New Version Current
Changes made by

Kyle Miller (Deactivated)

Bala Harish A(AC)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Here is a top-level view of typical issues to resolve before launching a production implementation of a Swarm cluster. These topics are covered in the sections that follow.

Hardware

  • Swarm nodes meet minimum requirements:

    • CPU: Intel or AMD, 64-bit, 2+ cores

    • RAM: Sufficient memory available for anticipated object count

    • Drives: SATA, SAS, or SCSI – enterprise-class with 24x7 duty cycle

  • Network: 1000 Mbps or faster (100 Mbps minimum) – multiple interfaces if redundancy required

Number

  • The number of nodes is greater than the number of configured replicas and EC k+p

  • Sufficient free space in the cluster to recover content if a node fails?

Booting Type

  • Platform Server, or

  • Self-boot options:

    • USB booting? Verify configuration files are the same.

    • PXE/network booting?

    • Centralized configuration files?

Network Management

  • DHCP or static IP addressing?

  • The NTP server is configured and available.

  • Syslog server is configured and available; configured local6* and log rotation policy.

  • Network filters are configured to

ensure only

  • verify that authorized users can reach the cluster.

  • DNS names for nodes are set up.

  • Network switch redundancy is sufficient for your deployment.

  • Monitoring procedures are in place: SNMP or assigned administrator watching console.

  • Verified bandwidth to cluster nodes.

  • Defined Swarm bonding mode (active-backup, balance-alb, or 802.3ad).

Storage Config

  • The 

administrator 

  • administrator and 

operator 

  • operator default passwords

have been

  • are updated to a new, secure value.

  • The node and/or cluster configuration file is updated and validated.

Data Protection

  • Does the default number of replicas (policy.replicas default) meet your protection requirements?

  • Does the default EC ratio (policy.ecEncoding) meet your protection requirements?

  • Set lifepoints 'reps' for necessary file types?

  • File retention period and deleteability (yes or no) defined in lifepoints?

Any

  • Are any non-deletable files or automatic delete lifepoints?

  • UUID management mechanism protected (database or other means) if not using metadata search?

Default Domain

  • Set cluster.name to your desired default domain name, a valid IANA FQDN host name (cluster1.cloud.example.com)

  • Create a domain that matches the value of cluster.name. This is the default domain for this cluster.

Set 

  • Set cluster.enforceTenancy = True

 to ensure that

  •  to verify unnamed content is homed in a default domain if no domain is specified

Application Setup

  • What storage protocols do your client applications use?

  • If using HTTPS (SSL/TLS), create appropriate X.509 certificates and install on encryption off-load hardware/software.

  • SCSP clients:

Make sure

    • Verify relevant custom metadata is defined in natively integrated client.

    • How does your application access the primary access node (PAN)?

    • Create user accounts and, optionally, authentication tokens.

  • S3 clients:

    • Create S3 authentication tokens for applications

    • Method for directing SCSP and S3 requests to the appropriate Gateway port?

Testing

  • Conduct end-to-end testing of the exact hardware, network setup, and software version to be used in production to

ensure

  • verify there are no compatibility issues.

  • Test functionality using all client protocols.

Maintenance 

  • What is your disk drive replacement strategy?

  • What are your maintenance windows for software updates?

  • Do you use staging or testing environments to pre-qualify updates?