No matter which OS you use, the minimum hardware recommendations are as follows:
- 2 CPU
- 4GB Memory
- 30 GB Storage
Deployer Server Requirements¶
- Ubuntu 16.04 or later
- Debian 7 or later (not tested)
Refer to the Debian based setup
The punchplatform deployer is supported on these operating systems:
- CentOS 7 or later
- RedHat 7 or later (not tested)
Refer to the CentOS based setup
Follow this Darwin based setup
Target Server Requirements¶
The target servers are the ones installed with binaries and configurations to run the punch components. The punch deployer tool internally leverage ansible.
Make sure you conform to the following requirements.
- All network interfaces are up and configured.
- Storage partitions are writable and mounted except for Ceph intended block device to manage.
Administration access: An administration account must be provided and access with SSH from the installation environment to the servers.
This account must be
sudoersto update systemctl configuration for instance.
Naming resolution: Naming resolution must be configured. Short and long hostname are resolved.
When resolving from any target machine the hostname of itself or any other target machine (i.e. the return of 'hostname' command), the result must be the production network interface (as opposed to any other administration or supervision/monitoring dedicated network interface).
Time Synchronisation: A full time synchronisation infrastructure like NTP must be configured and running.
Repository: Standard repositories of the chosen operating system must be provided. To test the correct configuration, we recommend to update all servers before the punch deployment.
Internet access is ok, but private repository too.
For CentOS deployment,
EPELstandard repository must be enable and available.
system language: System language must be configured to
en_US.UTF-8.If this is not the case, change it :
localectl | grep LANG System Locale: LANG=en_US.utf8
sudo localectl set-locale LANG=en_US.utf8
The execution prerequisites are disclosed in Elasticsearch public documentation; the current section highlights some specificities that are often not identified during server/OS setup and may cause deployment problems
/tmppartition must not be mounted with
noexecoptions, otherwise Elasticsearch will fail its bootstrap checks with an error message in its log file :
system call filters failed to install
- Elasticsearch by default requires that its process memory may be locked to prevent swapping. The target servers (or virtual servers) must be able to deliver this feature (i.e. no specific hardening) should prevent Elasticsearch from requesting memory lock from the kernel. Elasticsearch checks this at startup time during its 'bootstrap checks' and fail if no/not enough memory could be locked.