diff --git a/docs/whpg/6x/admin_guide/analytics/procedural_languages/pl_java.md b/docs/whpg/6x/admin_guide/analytics/procedural_languages/pl_java.md index 874823d..48c4521 100644 --- a/docs/whpg/6x/admin_guide/analytics/procedural_languages/pl_java.md +++ b/docs/whpg/6x/admin_guide/analytics/procedural_languages/pl_java.md @@ -118,16 +118,6 @@ The commands that you use to install Java depend on the host system operating sy For OpenJDK 8 the version is `1.8.0`, for OpenJDK 11 the version is `11`. -- RHEL 6/CentOS 6 - - - Java 8 - This `yum` command installs OpenJDK 8. - - ``` - $ sudo yum install java-1.8.0-openjdk-devel - ``` - - - Java 11 - Download the OpenJDK 11 tar file from [http://jdk.java.net/archive/](http://jdk.java.net/archive/) and install and configure the operating system to use Java 11. - 1. This example `tar` command installs the OpenJDK 11 in `/usr/lib/jvm`. ``` diff --git a/docs/whpg/6x/admin_guide/performance/wlmgmt/index.md b/docs/whpg/6x/admin_guide/performance/wlmgmt/index.md index f91a5ff..573b8dc 100644 --- a/docs/whpg/6x/admin_guide/performance/wlmgmt/index.md +++ b/docs/whpg/6x/admin_guide/performance/wlmgmt/index.md @@ -11,10 +11,6 @@ WarehousePG provides features to help you prioritize and allocate resources to q You can use resource management features to limit the number of concurrent queries, the amount of memory used to run a query, and the relative amount of CPU devoted to processing a query. WarehousePG provides two schemes to manage resources - Resource Queues and Resource Groups. -> **Important** Significant WarehousePG performance degradation has been observed when enabling resource group-based workload management on RedHat 6.x and CentOS 6.x. This issue is caused by a Linux cgroup kernel bug. This kernel bug has been fixed in CentOS 7.x and Red Hat 7.x/8.x systems. - -If you use RedHat 6 and the performance with resource groups is acceptable for your use case, upgrade your kernel to version 2.6.32-696 or higher to benefit from other fixes to the cgroups implementation. - Either the resource queue or the resource group management scheme can be active in WarehousePG; both schemes cannot be active at the same time. Resource queues are enabled by default when you install your WarehousePG cluster. While you can create and assign resource groups when resource queues are active, you must explicitly enable resource groups to start using that management scheme. diff --git a/docs/whpg/6x/admin_guide/performance/wlmgmt/workload_mgmt_resgroups.md b/docs/whpg/6x/admin_guide/performance/wlmgmt/workload_mgmt_resgroups.md index de41682..f364bd3 100644 --- a/docs/whpg/6x/admin_guide/performance/wlmgmt/workload_mgmt_resgroups.md +++ b/docs/whpg/6x/admin_guide/performance/wlmgmt/workload_mgmt_resgroups.md @@ -287,10 +287,6 @@ Resource groups for roles track all WarehousePG memory allocated via the `palloc ## Configuring and Using Resource Groups -> **Important** Significant WarehousePG performance degradation has been observed when enabling resource group-based workload management on RedHat 6.x and CentOS 6.x systems. This issue is caused by a Linux cgroup kernel bug. This kernel bug has been fixed in CentOS 7.x and Red Hat 7.x/8.x systems. - -If you use RedHat 6 and the performance with resource groups is acceptable for your use case, upgrade your kernel to version 2.6.32-696 or higher to benefit from other fixes to the cgroups implementation. - ### Prerequisites @@ -326,9 +322,9 @@ Complete the following tasks on each node in your WarehousePG cluster to set up 2. Create the required cgroup hierarchies on each WarehousePG node. Since the hierarchies are cleaned when the operating system rebooted, a service is applied to recreate them automatically on boot. Follow the below steps based on your operating system version. -#### Redhat/CentOS 6.x/7.x/8.x +#### Redhat/CentOS 7.x/8.x -These operating systems include the `libcgroup-tools` package (for Redhat/CentOS 7.x/8.x) or `libcgroup` (for Redhat/CentOS 6.x) +These operating systems include the `libcgroup-tools` package. 1. Locate the cgroups configuration file `/etc/cgconfig.conf`. You must be the superuser or have `sudo` access to edit this file: @@ -365,35 +361,21 @@ These operating systems include the `libcgroup-tools` package (for Redhat/CentOS 3. Start the cgroups service on each WarehousePG node. You must be the superuser or have `sudo` access to run the command: - - Redhat/CentOS 7.x/8.x systems: - - ``` - cgconfigparser -l /etc/cgconfig.conf - ``` - - Redhat/CentOS 6.x systems: - - ``` - service cgconfig start - ``` - -4. To automatically recreate WarehousePG required cgroup hierarchies and parameters when your system is restarted, configure your system to enable the Linux cgroup service daemon `cgconfig.service` (Redhat/CentOS 7.x/8.x) or `cgconfig` (Redhat/CentOS 6.x) at node start-up. To ensure the configuration is persistent after reboot, run the following commands as user root: - - - Redhat/CentOS 7.x/8.x systems: + ``` + cgconfigparser -l /etc/cgconfig.conf + ``` - ``` - systemctl enable cgconfig.service - ``` +4. To automatically recreate WarehousePG required cgroup hierarchies and parameters when your system is restarted, configure your system to enable the Linux cgroup service daemon `cgconfig.service` at node start-up. To ensure the configuration is persistent after reboot, run the following commands as user root: - To start the service immediately (without having to reboot) enter: + ``` + systemctl enable cgconfig.service + ``` - ``` - systemctl start cgconfig.service - ``` - - Redhat/CentOS 6.x systems: + To start the service immediately (without having to reboot) enter: - ``` - chkconfig cgconfig on - ``` + ``` + systemctl start cgconfig.service + ``` 5. Identify the `cgroup` directory mount point for the node: diff --git a/docs/whpg/6x/install_guide/config_os.md b/docs/whpg/6x/install_guide/config_os.md index 3a38b03..5ede4a6 100644 --- a/docs/whpg/6x/install_guide/config_os.md +++ b/docs/whpg/6x/install_guide/config_os.md @@ -49,6 +49,10 @@ If you choose to deactivate SELinux: SELINUX=disabled ``` + ::: info Note + After editing the config file, rerun `sestatus` and confirm `Mode from config file: disabled`. That field reads `/etc/selinux/config` directly and reflects your edit immediately. `SELinux status:` and `Current mode:` show the state the running kernel loaded at boot, and continue to show the previous state until you reboot. + ::: + 3. If the System Security Services Daemon (SSSD) is installed on your systems, edit the SSSD configuration file and set the `selinux_provider` parameter to `none` to prevent SELinux-related SSH authentication denials that could occur even with SELinux deactivated. As root, edit `/etc/sssd/sssd.conf` and add this parameter: ``` @@ -63,7 +67,7 @@ If you choose to enable SELinux in `Enforcing` mode, then WarehousePG processes ## Deactivate or Configure Firewall Software -You should also deactivate firewall software such as `iptables` (on systems such as RHEL 6.x and CentOS 6.x) or `firewalld` (on systems such as RHEL 7.x and CentOS 7.x and later). If firewall software is not deactivated, you must instead configure your software to allow required communication between WarehousePG hosts. +You should also deactivate firewall software such as `iptables` or `firewalld`. If firewall software is not deactivated, you must instead configure your software to allow required communication between WarehousePG hosts. To deactivate `iptables`: @@ -105,9 +109,13 @@ To deactivate `iptables`: ``` # systemctl stop firewalld.service - # systemctl deactivate firewalld.service + # systemctl disable firewalld.service ``` + ::: info Note + On some machine images, `firewalld` isn't installed. In that case, `systemctl stop firewalld.service` returns `Failed to stop firewalld.service: Unit firewalld.service not loaded`, and `systemctl disable firewalld.service` fails with its own `unit not found` message. Both errors are harmless. If `firewalld` isn't installed, it's already effectively deactivated, and no further action is needed. + ::: + If you decide to enable `iptables` with WarehousePG for security purposes, see [Enabling iptables (Optional)](enable_iptables.md) for important considerations and example configurations. See the documentation for the firewall or your operating system for additional information. @@ -120,7 +128,7 @@ WarehousePG requires that certain Linux operating system (OS) parameters be set In general, the following categories of system parameters need to be altered: -- **Shared Memory** - A WarehousePG instance will not work unless the shared memory segment for your kernel is properly sized. Most default OS installations have the shared memory values set too low for WarehousePG. On Linux systems, you must also deactivate the OOM (out of memory) killer. For information about WarehousePG shared memory requirements, see the WarehousePG server configuration parameter [shared_buffers](../ref_guide/config_params/guc-list.md) in the *WarehousePG Reference Guide*. +- **Shared Memory** - A WarehousePG instance will not work unless the shared memory segment for your kernel is properly sized. Most default OS installations have the shared memory values set too low for WarehousePG. On Linux systems, you must also deactivate the OOM (out of memory) killer. For information about WarehousePG shared memory requirements, see the WarehousePG server configuration parameter [shared_buffers](../ref_guide/config_params/guc-list.md#shared_buffers) in the *WarehousePG Reference Guide*. - **Network** - On high-volume WarehousePG clusters, certain network-related tuning parameters must be set to optimize network connections made by the WarehousePG interconnect. - **User Limits** - User limits control the resources available to processes started by a user's shell. WarehousePG requires a higher limit on the allowed number of file descriptors that a single process can have open. The default settings may cause some WarehousePG queries to fail because they will run out of file descriptors needed to process the query. @@ -153,6 +161,10 @@ The `sysctl.conf` parameters listed in this topic are for performance, optimizat Set the parameters in the `/etc/sysctl.conf` file and reload with `sysctl -p`: +:::: warning Caution +The `kernel.shmall`, `kernel.shmmax`, and `vm.overcommit_ratio` values in this example are calculated for a specific host with 1583 GB of memory. Don't copy these values as-is to a host with a different amount of memory. A `vm.overcommit_ratio` that's too high for the host's actual memory can produce the same `could not map anonymous shared memory` failure covered in [Troubleshooting Initialization Problems](init_whpg.md#topic7). Calculate `kernel.shmall` and `kernel.shmmax` for your own host as described in [Shared Memory Pages](#shared-memory-pages) below, and `vm.overcommit_ratio` as described in [Segment Host Memory](#segment-host-memory) below, then substitute your calculated values in the file. +:::: + ``` # kernel.shmall = _PHYS_PAGES / 2 # See Shared Memory Pages @@ -206,8 +218,8 @@ kernel.shmmax = ( _PHYS_PAGES / 2) * PAGE_SIZE To calculate the values for `kernel.shmall` and `kernel.shmmax`, run the following commands using the `getconf` command, which returns the value of an operating system variable. ``` -$ echo $(expr $(getconf _PHYS_PAGES) / 2) -$ echo $(expr $(getconf _PHYS_PAGES) / 2 \* $(getconf PAGE_SIZE)) +echo $(expr $(getconf _PHYS_PAGES) / 2) +echo $(expr $(getconf _PHYS_PAGES) / 2 \* $(getconf PAGE_SIZE)) ``` As best practice, we recommend you set the following values in the `/etc/sysctl.conf` file using calculated values. For example, a host system has 1583 GB of memory installed and returns these values: \_PHYS_PAGES = 395903676 and PAGE_SIZE = 4096. These would be the `kernel.shmall` and `kernel.shmmax` values: @@ -495,22 +507,15 @@ You may control the value of the MTU at various locations: These settings are connected, in that they should always be either the same, or close to the same, value, or otherwise in the order of WarehousePG < Operating System < Virtual or Physical switch for MTU size. +If the interconnect network supports jumbo frames, set the MTU to 9000 and keep `gp_max_packet_size` at its default of 8192. If the network doesn't support jumbo frames and the MTU is 1500, reduce `gp_max_packet_size` to 1472 to avoid fragmented packets. + 9000 is a common supported setting for switches, and is the recommended OS and rack switch MTU setting for your WarehousePG hosts. ### Transparent Huge Pages (THP) -Deactivate Transparent Huge Pages (THP) as it degrades WarehousePG performance. RHEL 6.0 or higher enables THP by default. One way to deactivate THP on RHEL 6.x is by adding the parameter `transparent_hugepage=never` to the kernel command in the file `/boot/grub/grub.conf`, the GRUB boot loader configuration file. This is an example kernel command from a `grub.conf` file. The command is on multiple lines for readability: - -``` -kernel /vmlinuz-2.6.18-274.3.1.el5 ro root=LABEL=/ - elevator=deadline crashkernel=128M@16M quiet console=tty1 - console=ttyS1,115200 panic=30 transparent_hugepage=never - initrd /initrd-2.6.18-274.3.1.el5.img -``` - -On systems that use `grub2` such as RHEL 7.x or CentOS 7.x and later, use the system utility `grubby`. This command adds the parameter when run as root. +Deactivate Transparent Huge Pages (THP) as it degrades WarehousePG performance. On systems that use `grub2`, such as RHEL 7.x or CentOS 7.x and later, use the system utility `grubby`. This command adds the parameter when run as root. ``` # grubby --update-kernel=ALL --args="transparent_hugepage=never" @@ -521,7 +526,8 @@ After adding the parameter, reboot the system. This cat command checks the state of THP. The output indicates that THP is deactivated. ``` -$ cat /sys/kernel/mm/*transparent_hugepage/enabled +cat /sys/kernel/mm/*transparent_hugepage/enabled +__OUTPUT__ always [never] ``` @@ -570,10 +576,10 @@ Max Startups 10:30:200 MaxSessions 200 ``` -Restart the SSH daemon after you update `MaxStartups` and `MaxSessions`. For example, on a CentOS 6 system, run the following command as the `root` user: +Restart the SSH daemon after you update `MaxStartups` and `MaxSessions`. For example, run the following command as the `root` user: ``` -# service sshd restart +# systemctl restart sshd ``` For detailed information about SSH configuration options, refer to the SSH documentation for your Linux distribution. @@ -686,7 +692,7 @@ The `gpadmin` user must have permission to access the services and directories r The `gpadmin` user on each WarehousePG host must have an SSH key pair installed and be able to SSH from any host in the cluster to any other host in the cluster without entering a password or passphrase (called "passwordless SSH"). If you enable passwordless SSH from the coordinator host to every other host in the cluster ("1-*n* passwordless SSH"), you can use the WarehousePG `gpssh-exkeys` command-line utility later to enable passwordless SSH from every host to every other host ("*n*-*n* passwordless SSH"). -You can optionally give the `gpadmin` user sudo privilege, so that you can easily administer all hosts in the WarehousePG cluster as `gpadmin` using the `sudo`, `ssh/scp`, and `gpssh/gpscp` commands. +You can optionally give the `gpadmin` user sudo privilege, so that you can administer all hosts in the WarehousePG cluster as `gpadmin` using the `sudo`, `ssh/scp`, and `gpssh/gpscp` commands. The following steps show how to set up the `gpadmin` user on a host, set a password, create an SSH key pair, and (optionally) enable sudo capability. These steps must be performed as root on every WarehousePG cluster host. (For a large WarehousePG cluster you will want to automate these steps using your system provisioning tools.) @@ -702,19 +708,21 @@ The following steps show how to set up the `gpadmin` user on a host, set a passw # groupadd gpadmin # useradd gpadmin -r -m -g gpadmin # passwd gpadmin + __OUTPUT__ New password: Retype new password: ``` > **Note** You must have root permission to create the `gpadmin` group and user. - > **Note** Make sure the `gpadmin` user has the same user id (uid) and group id (gid) numbers on each host to prevent problems with scripts or services that use them for identity or permissions. For example, backing up WarehousePGs to some networked filesy stems or storage appliances could fail if the `gpadmin` user has different uid or gid numbers on different segment hosts. When you create the `gpadmin` group and user, you can use the `groupadd -g` option to specify a gid number and the `useradd -u` option to specify the uid number. Use the command `id gpadmin` to see the uid and gid for the `gpadmin` user on the current host. + > **Note** Make sure the `gpadmin` user has the same user id (uid) and group id (gid) numbers on each host to prevent problems with scripts or services that use them for identity or permissions. For example, backing up WarehousePGs to some networked filesystems or storage appliances could fail if the `gpadmin` user has different uid or gid numbers on different segment hosts. When you create the `gpadmin` group and user, you can use the `groupadd -g` option to specify a gid number and the `useradd -u` option to specify the uid number. Use the command `id gpadmin` to see the uid and gid for the `gpadmin` user on the current host. 2. Switch to the `gpadmin` user and generate an SSH key pair for the `gpadmin` user. ``` - $ su gpadmin - $ ssh-keygen -t rsa -b 4096 + su gpadmin + ssh-keygen -t rsa -b 4096 + __OUTPUT__ Generating public/private rsa key pair. Enter file in which to save the key (/home/gpadmin/.ssh/id_rsa): Created directory '/home/gpadmin/.ssh'. @@ -727,6 +735,10 @@ The following steps show how to set up the `gpadmin` user on a host, set a passw 3. Grant sudo access to the `gpadmin` user. + ::: info Note + This step is optional, but it's helpful, and it simplifies some procedures elsewhere in this guide, such as [Creating the Data Storage Areas](create_data_dirs.md), that run `sudo` commands on remote hosts through `gpssh`. If `gpadmin` doesn't have sudo access, you can't use `gpssh` or `gpscp` to run those commands. Because `gpssh` provides no terminal for a password prompt, the grant must let `gpadmin` run `sudo` without a password (`NOPASSWD`), as shown below, for those procedures to work. + ::: + On Red Hat or CentOS, run `visudo` and uncomment the `%wheel` group entry. ``` diff --git a/docs/whpg/6x/install_guide/create_data_dirs.md b/docs/whpg/6x/install_guide/create_data_dirs.md index 1576384..9ed9e7c 100644 --- a/docs/whpg/6x/install_guide/create_data_dirs.md +++ b/docs/whpg/6x/install_guide/create_data_dirs.md @@ -19,24 +19,24 @@ A data storage area is required on the WarehousePG coordinator and standby coord The data directory location on the coordinator is different than those on the segments. The coordinator does not store any user data, only the system catalog tables and system metadata are stored on the coordinator instance, therefore you do not need to designate as much storage space as on the segments. -1. Create or choose a directory that will serve as your coordinator data storage area. This directory should have sufficient disk space for your data and be owned by the `gpadmin` user and group. For example, run the following commands as `root`: +1. Create or choose a directory that will serve as your coordinator data storage area. This directory should have sufficient disk space for your data and be owned by the `gpadmin` user and group. For example, run the following command using `sudo`: ``` - # mkdir -p /data/master + sudo mkdir -p /data/master ``` -2. Change ownership of this directory to the `gpadmin` user. For example: +2. Change ownership of this directory, and any parent directories you created, to the `gpadmin` user. For example: ``` - # chown gpadmin:gpadmin /data/master + sudo chown gpadmin:gpadmin /data + sudo chown -R gpadmin:gpadmin /data/master ``` -3. Using [gpssh](../ref_guide/utility_guide/reference/gpssh.md), create the coordinator data directory location on your standby coordinator as well. For example: +3. As the `gpadmin` user, use [gpssh](../ref_guide/utility_guide/reference/gpssh.md) to create the coordinator data directory location on your standby coordinator as well. For example: ``` - # source /usr/edb/whpg6/greenplum_path.sh - # gpssh -h smdw -e 'mkdir -p /data/master' - # gpssh -h smdw -e 'chown gpadmin:gpadmin /data/master' + gpssh -h smdw -e 'sudo mkdir -p /data/master' + gpssh -h smdw -e 'sudo chown -R gpadmin:gpadmin /data/master' ``` @@ -49,12 +49,17 @@ Data storage areas are required on the WarehousePG segment hosts for primary seg ### To create the data directory locations on all segment hosts -1. On the coordinator host, log in as `root`: +1. On the coordinator host, switch to the `gpadmin` user and source the `greenplum_path.sh` file. ``` - # su + sudo -iu gpadmin + source /usr/local/greenplum-db/greenplum_path.sh ``` + ::: info Note + Logging in as `root` with `su` fails on hosts where root login is deactivated, such as Amazon EC2 instances. The `gpssh` commands in this topic use `sudo` on the remote hosts instead, so you can run them as `gpadmin`, provided `gpadmin` has `sudo` privilege as described in [Creating the WarehousePG Administrative User](config_os.md#topic23). + ::: + 2. Create a file called `hostfile_gpssh_segonly`. This file should have only one machine configured host name for each segment host. For example, if you have three segment hosts: ``` @@ -66,14 +71,17 @@ Data storage areas are required on the WarehousePG segment hosts for primary seg 3. Using [gpssh](../ref_guide/utility_guide/reference/gpssh.md), create the primary and mirror data directory locations on all segment hosts at once using the `hostfile_gpssh_segonly` file you just created. For example: ``` - # source /usr/edb/whpg6/greenplum_path.sh - # gpssh -f hostfile_gpssh_segonly -e 'mkdir -p /data1/primary' - # gpssh -f hostfile_gpssh_segonly -e 'mkdir -p /data2/primary' - # gpssh -f hostfile_gpssh_segonly -e 'mkdir -p /data1/mirror' - # gpssh -f hostfile_gpssh_segonly -e 'mkdir -p /data2/mirror' - # gpssh -f hostfile_gpssh_segonly -e 'chown -R gpadmin /data*/*' + gpssh -f hostfile_gpssh_segonly -e 'sudo mkdir -p /data1/primary' + gpssh -f hostfile_gpssh_segonly -e 'sudo mkdir -p /data2/primary' + gpssh -f hostfile_gpssh_segonly -e 'sudo mkdir -p /data1/mirror' + gpssh -f hostfile_gpssh_segonly -e 'sudo mkdir -p /data2/mirror' + gpssh -f hostfile_gpssh_segonly -e 'sudo chown -R gpadmin:gpadmin /data1 /data2' ``` + ::: warning Caution + Use `chown -R gpadmin:gpadmin /data1 /data2` rather than `chown -R gpadmin /data*/*`. The latter sets only the owner, not the group, so the primary and mirror directories stay in the `root` group. Setting both the owner and group to `gpadmin` avoids permission problems later. + ::: + ## Next Steps diff --git a/docs/whpg/6x/install_guide/init_whpg.md b/docs/whpg/6x/install_guide/init_whpg.md index 360ba74..1c6cbba 100644 --- a/docs/whpg/6x/install_guide/init_whpg.md +++ b/docs/whpg/6x/install_guide/init_whpg.md @@ -43,8 +43,8 @@ These are the high-level tasks for initializing WarehousePG: When performing the following initialization tasks, you must be logged into the coordinator host as the `gpadmin` user, and to run WarehousePG utilities, you must source the `greenplum_path.sh` file to set WarehousePG environment variables. For example, if you are logged into the coordinator, run these commands. ``` -$ su - gpadmin -$ source /usr/edb/whpg6/greenplum_path.sh +su - gpadmin +source /usr/edb/whpg6/greenplum_path.sh ``` @@ -88,17 +88,33 @@ Your WarehousePG configuration file tells the [gpinitsystem](../ref_guide/utilit #### To create a gpinitsystem_config file -1. Make a copy of the `gpinitsystem_config` file to use as a starting point. For example: +1. Create the `gpconfigs` directory in the `gpadmin` home directory, if it doesn't already exist, then make a copy of the `gpinitsystem_config` file to use as a starting point. For example: ``` - $ cp $GPHOME/docs/cli_help/gpconfigs/gpinitsystem_config \ - /home/gpadmin/gpconfigs/gpinitsystem_config + mkdir -p ~/gpconfigs + cp $GPHOME/docs/cli_help/gpconfigs/gpinitsystem_config \ + ~/gpconfigs/gpinitsystem_config ``` 2. Open the file you just copied in a text editor. Set all of the required parameters according to your environment. See [gpinitsystem](../ref_guide/utility_guide/reference/gpinitsystem.md) for more information. A WarehousePG cluster must contain a coordinator instance and at *least two* segment instances (even if setting up a single node system). + The `gpinitsystem_config` file is heavily commented. These are the parameters marked **Required** in the [gpinitsystem](../ref_guide/utility_guide/reference/gpinitsystem.md) reference. All other parameters in the file, including the mirror parameters covered in step 3 below, are optional and can be left at their default values. + + | Parameter | Description | Example value | + |---|---|---| + | `ARRAY_NAME` | Name for the cluster | `"WHPG Cluster"` | + | `SEG_PREFIX` | Prefix for segment data directories | `gpseg` | + | `PORT_BASE` | Base port for primary segments | `6000` | + | `DATA_DIRECTORY` | Primary segment data directories, one entry per segment per host | `(/data1/primary /data2/primary)` | + | `MASTER_HOSTNAME` | Hostname of the coordinator host | `mdw` | + | `MASTER_DIRECTORY` | Coordinator data directory | `/data/master` | + | `MASTER_PORT` | Coordinator port | `5432` | + | `TRUSTED_SHELL` | Shell `gpinitsystem` uses to run commands on remote hosts | `ssh` | + | `CHECK_POINT_SEGMENTS` | Maximum distance between automatic WAL checkpoints, in log file segments | `8` | + | `ENCODING` | Character set encoding | `UNICODE` | + The `DATA_DIRECTORY` parameter is what determines how many segments per host will be created. If your segment hosts have multiple network interfaces, and you used their interface address names in your host file, the number of segments will be evenly spread over the number of available interfaces. To specify `PORT_BASE`, review the port range specified in the `net.ipv4.ip_local_port_range` parameter in the `/etc/sysctl.conf` file. See [Recommended OS Parameters Settings](config_os.md). @@ -112,7 +128,7 @@ Your WarehousePG configuration file tells the [gpinitsystem](../ref_guide/utilit MASTER_HOSTNAME=mdw MASTER_DIRECTORY=/data/master MASTER_PORT=5432 - TRUSTED SHELL=ssh + TRUSTED_SHELL=ssh CHECK_POINT_SEGMENTS=8 ENCODING=UNICODE ``` @@ -140,24 +156,23 @@ These steps assume you are logged in as the `gpadmin` user and have sourced the #### To run the initialization utility -1. Run the following command referencing the path and file name of your initialization configuration file (`gpinitsystem_config`) and host file (`hostfile_gpinitsystem`). For example: +1. Run the following command referencing the path and file name of your initialization configuration file (`gpinitsystem_config`) and host file (`hostfile_gpinitsystem`). Use absolute paths (or paths relative to `$HOME`, as shown here), so the command works regardless of your current working directory. For example: ``` - $ cd ~ - $ gpinitsystem -c gpconfigs/gpinitsystem_config -h gpconfigs/hostfile_gpinitsystem + gpinitsystem -c ~/gpconfigs/gpinitsystem_config -h ~/gpconfigs/hostfile_gpinitsystem ``` For a fully redundant system (with a standby coordinator and a *spread* mirror configuration) include the `-s` and `--mirror-mode=spread` options. For example: ``` - $ gpinitsystem -c gpconfigs/gpinitsystem_config -h gpconfigs/hostfile_gpinitsystem \ + gpinitsystem -c ~/gpconfigs/gpinitsystem_config -h ~/gpconfigs/hostfile_gpinitsystem \ -s --mirror-mode=spread ``` During a new cluster creation, you may use the `-O output\_configuration\_file` option to save the cluster configuration details in a file. For example: ``` - $ gpinitsystem -c gpconfigs/gpinitsystem_config -O gpconfigs/config_template + gpinitsystem -c ~/gpconfigs/gpinitsystem_config -O ~/gpconfigs/config_template ``` This output file can be edited and used at a later stage as the input file of the `-I` option, to create a new cluster or to recover from a backup. See [gpinitsystem](../ref_guide/utility_guide/reference/gpinitsystem.md) for further details. @@ -186,7 +201,15 @@ These steps assume you are logged in as the `gpadmin` user and have sourced the If the utility encounters any errors while setting up an instance, the entire process will fail, and could possibly leave you with a partially created system. Refer to the error messages and logs to determine the cause of the failure and where in the process the failure occurred. Log files are created in `~/gpAdminLogs`. -Depending on when the error occurred in the process, you may need to clean up and then try the `gpinitsystem` utility again. For example, if some segment instances were created and some failed, you may need to stop `postgres` processes and remove any utility-created data directories from your data storage area(s). A backout script is created to help with this cleanup if necessary. +The top-level log entries, such as `Failed to start segment instance database` or `Errors generated from parallel processes`, only report that a failure occurred, not the underlying cause. The actual cause is usually further down in the same log file. To find it, search the `gpinitsystem` log for the host and initialization run you want to check. The log file is appended to on every run for the day, so check the timestamps on the matched lines to make sure you're looking at the run that just failed. + +``` +grep -E 'FATAL|ERROR|error' ~/gpAdminLogs/gpinitsystem_.log | tail -20 +``` + +If the result includes `could not map anonymous shared memory: Cannot allocate memory`, the host likely doesn't have enough memory for the configured `max_connections` (default: 250 on the coordinator and 750 on segments, which is always 3x the coordinator value). This shortage is common on smaller hosts. Set a lower value, such as `MASTER_MAX_CONNECT=50`, in your `gpinitsystem_config` file (or pass `-m 50` to `gpinitsystem`) and retry. + +Depending on when the error occurred in the process, you may need to clean up and then try the `gpinitsystem` utility again. For example, if some segment instances were created and some failed, you may need to stop `postgres` processes and remove any utility-created data directories from your data storage area(s). A backout script is created to help with this cleanup if necessary. Don't rerun `gpinitsystem` before you clean up. Retrying without running the backout script first fails immediately with an error such as `Master host data directory already exists`. @@ -201,7 +224,7 @@ You can use this script to clean up a partially created WarehousePG cluster. Thi The following example shows how to run the backout script: ``` -$ bash ~/gpAdminLogs/backout_gpinitsystem_gpadmin_20071031_121053 +bash ~/gpAdminLogs/backout_gpinitsystem_gpadmin_20071031_121053 ``` @@ -213,8 +236,8 @@ As a best practice, configure WarehousePG and the host systems to use a known, s Use the [gpconfig](../ref_guide/utility_guide/reference/gpconfig.md) utility to show and set the WarehousePG timezone. For example, these commands show the WarehousePG timezone and set the timezone to `US/Pacific`. ``` -$ gpconfig -s TimeZone -$ gpconfig -c TimeZone -v 'US/Pacific' +gpconfig -s TimeZone +gpconfig -c TimeZone -v 'US/Pacific' ``` You must restart WarehousePG after changing the timezone. The command `gpstop -ra` restarts WarehousePG. The catalog view `pg_timezone_names` provides WarehousePG timezone information. @@ -240,7 +263,7 @@ These steps ensure that the environment variables are set for the `gpadmin` user 1. Open the `gpadmin` profile file (such as `.bashrc`) in a text editor. For example: ``` - $ vi ~/.bashrc + vi ~/.bashrc ``` 2. Add lines to this file to source the `greenplum_path.sh` file and set the `MASTER_DATA_DIRECTORY` environment variable. For example: @@ -269,15 +292,15 @@ These steps ensure that the environment variables are set for the `gpadmin` user 6. After editing the profile file, source it to make the changes active. For example: ``` - $ source ~/.bashrc + source ~/.bashrc ``` 7. If you have a standby coordinator host, copy your environment file to the standby coordinator as well. For example: ``` - $ cd ~ - $ scp .bashrc :`pwd` + cd ~ + scp .bashrc :`pwd` ``` > **Note** The `.bashrc` file should not produce any output. If you wish to have a message display to users upon logging in, use the `.bash_profile` file instead. diff --git a/docs/whpg/6x/install_guide/install_whpg.md b/docs/whpg/6x/install_guide/install_whpg.md index b3a12d9..d4c4bc9 100644 --- a/docs/whpg/6x/install_guide/install_whpg.md +++ b/docs/whpg/6x/install_guide/install_whpg.md @@ -56,16 +56,26 @@ Follow these instructions to install WarehousePG from a pre-built binary. - For RHEL/CentOS systems, run the `yum` command: ``` - $ sudo yum install ./greenplum-db--.rpm + sudo yum install ./greenplum-db--.rpm ``` The `yum` command automatically installs software dependencies, copies the WarehousePG software files into a version-specific directory under `/usr/local`, `/usr/local/greenplum-db-`, and creates the symbolic link `/usr/local/greenplum-db` to the installation directory. + ::: info Note + If a subsequent `yum` command hangs waiting for the RPM lock, another process is still holding it, for example an interrupted `yum` whose transaction hasn't finished, or a background updater such as `packagekitd`. Identify it, then let it finish or stop it. The lock releases as soon as the process exits. + + ``` + sudo fuser -v /var/lib/rpm/.rpm.lock + sudo kill + ``` + + Don't delete `/var/lib/rpm/.rpm.lock`. Removing it while a process still holds it can corrupt the RPM database. + ::: + 3. Change the owner and group of the installed files to `gpadmin`: ``` - $ sudo chown -R gpadmin:gpadmin /usr/local/greenplum* - $ sudo chgrp -R gpadmin /usr/local/greenplum* + sudo chown -R gpadmin:gpadmin /usr/local/greenplum* ``` @@ -83,14 +93,14 @@ Follow these instructions to install WarehousePG to a specific directory. 2. Manually install the WarehousePG dependencies to each host system: ``` - $ sudo yum install apr apr-util bash bzip2 curl krb5 libcurl libevent \ + sudo yum install apr apr-util bash bzip2 curl krb5 libcurl libevent \ libxml2 libyaml zlib openldap openssh openssl openssl-libs perl readline rsync R sed tar zip ``` 3. Use `rpm` with the `--prefix` option to install the WarehousePG package to your chosen installation directory on each host machine: ``` - $ sudo rpm --install ./greenplum-db--.rpm --prefix= + sudo rpm --install ./greenplum-db--.rpm --prefix= ``` The `rpm` command copies the WarehousePG software files into a version-specific directory under your chosen ``, `/greenplum-db-`, and creates the symbolic link `/greenplum-db` to the versioned directory. @@ -98,7 +108,7 @@ Follow these instructions to install WarehousePG to a specific directory. 4. Change the owner and group of the installed files to `gpadmin`: ``` - $ sudo chown -R gpadmin:gpadmin /greenplum* + sudo chown -R gpadmin:gpadmin /greenplum* ``` > **Note** All example procedures in the WarehousePG documentation assume that you installed to the default directory, which is `/usr/local`. If you install to a non-default directory, substitute that directory for `/usr/local`. @@ -116,26 +126,53 @@ The `gpadmin` user on each WarehousePG host must be able to SSH from any host in 2. Source the `path` file in the WarehousePG installation directory. ``` - $ source /usr/local/greenplum-db-/greenplum_path.sh + source /usr/local/greenplum-db-/greenplum_path.sh ``` > **Note** Add the above `source` command to the `gpadmin` user's `.bashrc` or other shell startup file so that the WarehousePG path and environment variables are set whenever you log in as `gpadmin`. -3. Use the `ssh-copy-id` command to add the `gpadmin` user's public key to the `authorized_hosts` SSH file on every other host in the cluster. +3. Use the `ssh-copy-id` command to add the `gpadmin` user's public key to the `authorized_keys` SSH file on every other host in the cluster. ``` - $ ssh-copy-id smdw - $ ssh-copy-id sdw1 - $ ssh-copy-id sdw2 - $ ssh-copy-id sdw3 + ssh-copy-id smdw + ssh-copy-id sdw1 + ssh-copy-id sdw2 + ssh-copy-id sdw3 . . . ``` This enables 1-*n* passwordless SSH. You will be prompted to enter the `gpadmin` user's password for each host. If you have the `sshpass` command on your system, you can use a command like the following to avoid the prompt. ``` - $ SSHPASS= sshpass -e ssh-copy-id smdw + SSHPASS= sshpass -e ssh-copy-id smdw + ``` + + Skip the `smdw` commands if your cluster doesn't have a standby coordinator host. + + ::: info Note + `ssh-copy-id` can fail with two different errors that need different fixes. + + `ERROR: No identities found` means the `gpadmin` user has no local SSH key pair, for example because it was provisioned by a script, such as the [Example Ansible Playbook](ansible-example.md), that doesn't generate one. Generate a key pair as `gpadmin` on the coordinator, then retry `ssh-copy-id`. + + ``` + ssh-keygen -t rsa -b 4096 + ``` + + `Permission denied (publickey)` means a key pair exists, but the target host rejects password authentication, which cloud hosts such as Amazon EC2 instances often deactivate by default. In that case, copy the coordinator's public key to each host's `authorized_keys` file manually instead. On the coordinator, display the public key. + + ``` + cat /home/gpadmin/.ssh/id_rsa.pub + ``` + + Then, on each other host, create the `.ssh` directory if it doesn't already exist, append that key, and set the correct ownership and permissions. Run these commands as a user with `sudo` access, such as the default cloud image user. + + ``` + sudo install -d -m 700 -o gpadmin -g gpadmin /home/gpadmin/.ssh + echo "" | sudo tee -a /home/gpadmin/.ssh/authorized_keys + sudo chmod 600 /home/gpadmin/.ssh/authorized_keys + sudo chown -R gpadmin:gpadmin /home/gpadmin/.ssh ``` + ::: 4. In the `gpadmin` home directory, create a file named `hostfile_exkeys` that has the machine configured host names and host addresses (interface names) for each host in your WarehousePG cluster (coordinator, standby coordinator, and segment hosts). Make sure there are no blank lines or extra spaces. Check the `/etc/hosts` file on your systems for the correct host names to use for your environment. For example, if you have a coordinator, standby coordinator, and three segment hosts with two unbonded network interfaces per host, your file would look something like this: @@ -159,8 +196,16 @@ The `gpadmin` user on each WarehousePG host must be able to SSH from any host in 5. Run the `gpssh-exkeys` utility with your `hostfile_exkeys` file to enable *n*-*n* passwordless SSH for the `gpadmin` user. + `gpssh-exkeys` can fail with an error such as `No ECDSA host key is known for and you have requested strict checking` if your SSH client's strict host key checking rejects a host it doesn't yet recognize. To avoid this, populate `known_hosts` for every host in `hostfile_exkeys` first. + + ``` + ssh-keyscan -f hostfile_exkeys >> ~/.ssh/known_hosts + ``` + + Then run `gpssh-exkeys`. + ``` - $ gpssh-exkeys -f hostfile_exkeys + gpssh-exkeys -f hostfile_exkeys ``` @@ -172,13 +217,13 @@ To make sure the WarehousePG software was installed and configured correctly, ru 1. Log in to the coordinator host as `gpadmin`: ``` - $ su - gpadmin + su - gpadmin ``` 2. Use the `gpssh` utility to see if you can log in to all hosts without a password prompt, and to confirm that the WarehousePG software was installed on all hosts. Use the `hostfile_exkeys` file you used to set up passwordless SSH. For example: ``` - $ gpssh -f hostfile_exkeys -e 'ls -l /usr/local/greenplum-db-' + gpssh -f hostfile_exkeys -e 'ls -l /usr/local/greenplum-db-' ``` If the installation was successful, you should be able to log in to all hosts without a password prompt. All hosts should show that they have the same contents in their installation directories, and that the directories are owned by the `gpadmin` user. @@ -186,7 +231,7 @@ To make sure the WarehousePG software was installed and configured correctly, ru If you are prompted for a password, run the following command to redo the ssh key exchange: ``` - $ gpssh-exkeys -f hostfile_exkeys + gpssh-exkeys -f hostfile_exkeys ``` diff --git a/docs/whpg/6x/install_guide/platform-requirements.md b/docs/whpg/6x/install_guide/platform-requirements.md index 9390e6f..af1d5d5 100644 --- a/docs/whpg/6x/install_guide/platform-requirements.md +++ b/docs/whpg/6x/install_guide/platform-requirements.md @@ -14,11 +14,9 @@ WarehousePG 6 runs on the following operating system platforms: - Red Hat Enterprise Linux 64-bit 9.x - Red Hat Enterprise Linux 64-bit 8.7 or later (As of WarehousePG version 6.20. See the following [Note](#rhel-issues)) - Red Hat Enterprise Linux 64-bit 7.x (See the following [Note](#rhel-issues).) -- Red Hat Enterprise Linux 64-bit 6.x - Rocky Linux 9.x - Rocky Linux 8.7 or later - CentOS 64-bit 7.x -- CentOS 64-bit 6.x - Oracle Linux 64-bit 7, using the Red Hat Compatible Kernel (RHCK) @@ -26,9 +24,6 @@ WarehousePG 6 runs on the following operating system platforms: > **Note** If you use endpoint security software on your WarehousePG hosts, it may affect your database performance and stability. See [About Endpoint Security Sofware](../security-guide/index.md#endpoint_security) for more information. > **Caution** A kernel issue in Red Hat Enterprise Linux 8.5 and 8.6 can cause I/O freezes and synchronization problems with XFS filesystems. This issue is fixed in RHEL 8.7. See [RHEL8: xfs_buf deadlock between inode deletion and block allocation](https://access.redhat.com/solutions/6984334). -> Significant WarehousePG performance degradation has been observed when enabling resource group-based workload management on RedHat 6.x and CentOS 6.x systems. This issue is caused by a Linux cgroup kernel bug. This kernel bug has been fixed in CentOS 7.x and Red Hat 7.x/8.x systems. - -If you use RedHat 6 and the performance with resource groups is acceptable for your use case, upgrade your kernel to version 2.6.32-696 or higher to benefit from other fixes to the cgroups implementation. > **Caution** For WarehousePG that is installed on Red Hat Enterprise Linux 7.x or CentOS 7.x prior to 7.3, an operating system issue might cause WarehousePG that is running large workloads to hang in the workload. The WarehousePG issue is caused by Linux kernel bugs. @@ -42,7 +37,7 @@ WarehousePG server supports TLS version 1.2 and TLS version 1.3 on RHEL/CentOS s ### Software Dependencies -WarehousePG 6 requires the following software packages on RHEL/CentOS 6/7 systems which are installed automatically as dependencies when you install the WarehousePG RPM package): +WarehousePG 6 requires the following software packages on RHEL, CentOS, and Rocky Linux systems, which are installed automatically as dependencies when you install the WarehousePG RPM package: - apr - apr-util @@ -52,11 +47,9 @@ WarehousePG 6 requires the following software packages on RHEL/CentOS 6/7 system - compat-openssl11 (RHEL/Rocky 9) - iproute - krb5-devel -- libcgroup (RHEL/CentOS 6) - libcgroup-tools (RHEL/CentOS 7 and RHEL/Rocky 8) - libcurl - libevent (RHEL/CentOS 7 and RHEL/Rocky 8) -- libevent2 (RHEL/CentOS 6) - libuuid - libxml2 - libyaml @@ -86,7 +79,6 @@ WarehousePG 6 client software requires these operating system packages: - libedit - libyaml - libevent (RHEL/CentOS 7 and RHEL/Rocky 8) -- libevent2 (RHEL/CentOS 6) - openssh - zlib @@ -100,7 +92,7 @@ WarehousePG 6 uses Python 2.7.18, which is included with the product installatio ### Java -WarehousePGd 6 supports these Java versions for PL/Java and PXF: +WarehousePG 6 supports these Java versions for PL/Java and PXF: - Open JDK 8 or Open JDK 11, available from [AdoptOpenJDK](https://adoptopenjdk.net) - Oracle JDK 8 or Oracle JDK 11 @@ -165,10 +157,6 @@ These WarehousePG extensions are installed with WarehousePG - WarehousePG Connector for Apache NiFi v1.0.0 - The WarehousePG Connector for Apache NiFi enables you to set up a NiFi dataflow to load record-oriented data from any source into WarehousePG. -- WarehousePG Informatica Connector v1.0.5 - The WarehousePG Connector for Informatica supports high speed data transfer from an Informatica PowerCenter cluster to a WarehousePG cluster for batch and streaming ETL operations. - -- R2B X-LOG v5.x and v6.x - Real-time data replication solution that achieves high-speed database replication through the use of Redo Log Capturing method. - > **Note** WarehousePG 6 does not support the ODBC driver for Cognos Analytics V11. @@ -248,6 +236,10 @@ The disk settings for cloud deployments are the same as on-premise with a few mo ### Amazon Web Services (AWS) +#### Networking and Security Groups + +Deploy all coordinator, standby coordinator, and segment instances in the same virtual private cloud (VPC), and use each instance's private IP address, not its public IP address, for inter-node communication and connectivity tests. A security group that only allows inbound SSH from a jump host isn't enough for the WarehousePG interconnect traffic between instances. Add a dedicated security group with a self-referencing inbound rule that allows all traffic from other instances in the same group, and apply it to every coordinator, standby coordinator, and segment instance. + #### Virtual Machine Type diff --git a/docs/whpg/7x/install_guide/config_os.md b/docs/whpg/7x/install_guide/config_os.md index f3516fd..924433e 100644 --- a/docs/whpg/7x/install_guide/config_os.md +++ b/docs/whpg/7x/install_guide/config_os.md @@ -49,6 +49,10 @@ If you choose to deactivate SELinux: SELINUX=disabled ``` + ::: info Note + After editing the config file, rerun `sestatus` and confirm `Mode from config file: disabled`. That field reads `/etc/selinux/config` directly and reflects your edit immediately. `SELinux status:` and `Current mode:` show the state the running kernel loaded at boot, and continue to show the previous state until you reboot. + ::: + 3. If the System Security Services Daemon (SSSD) is installed on your systems, edit the SSSD configuration file and set the `selinux_provider` parameter to `none` to prevent SELinux-related SSH authentication denials that could occur even with SELinux deactivated. As root, edit `/etc/sssd/sssd.conf` and add this parameter: ``` @@ -86,6 +90,10 @@ You should also deactivate firewall software such as `firewalld` (on systems suc # systemctl disable firewalld.service ``` + ::: info Note + On some machine images, `firewalld` isn't installed. In that case, `systemctl stop firewalld.service` returns `Failed to stop firewalld.service: Unit firewalld.service not loaded`, and `systemctl disable firewalld.service` fails with its own `unit not found` message. Both errors are harmless. If `firewalld` isn't installed, it's already effectively deactivated, and no further action is needed. + ::: + See the documentation for the firewall or your operating system for additional information. @@ -96,7 +104,7 @@ WarehousePG requires that certain Linux operating system (OS) parameters be set In general, the following categories of system parameters need to be altered: -- **Shared Memory** - A WarehousePG instance will not work unless the shared memory segment for your kernel is properly sized. Most default OS installations have the shared memory values set too low for WarehousePG. On Linux systems, you must also deactivate the OOM (out of memory) killer. For information about WarehousePG shared memory requirements, see the WarehousePG server configuration parameter [shared_buffers](../ref_guide/config_params/guc-list.md) in the *WarehousePG Reference Guide*. +- **Shared Memory** - A WarehousePG instance will not work unless the shared memory segment for your kernel is properly sized. Most default OS installations have the shared memory values set too low for WarehousePG. On Linux systems, you must also deactivate the OOM (out of memory) killer. For information about WarehousePG shared memory requirements, see the WarehousePG server configuration parameter [shared_buffers](../ref_guide/config_params/guc-list.md#shared_buffers) in the *WarehousePG Reference Guide*. - **Network** - On high-volume WarehousePG clusters, certain network-related tuning parameters must be set to optimize network connections made by the WarehousePG interconnect. - **User Limits** - User limits control the resources available to processes started by a user's shell. WarehousePG requires a higher limit on the allowed number of file descriptors that a single process can have open. The default settings may cause some WarehousePG queries to fail because they will run out of file descriptors needed to process the query. @@ -129,6 +137,10 @@ The `sysctl.conf` parameters listed in this topic are for performance, optimizat Set the parameters in the `/etc/sysctl.conf` file and reload with `sysctl -p`: +:::: warning Caution +The `kernel.shmall`, `kernel.shmmax`, and `vm.overcommit_ratio` values in this example are calculated for a specific host with 1583 GB of memory. Don't copy these values as-is to a host with a different amount of memory. A `vm.overcommit_ratio` that's too high for the host's actual memory can produce the same `could not map anonymous shared memory` failure covered in [Troubleshooting Initialization Problems](init_whpg.md#topic7). Calculate `kernel.shmall` and `kernel.shmmax` for your own host as described in [Shared Memory Pages](#shared-memory-pages) below, and `vm.overcommit_ratio` as described in [Segment Host Memory](#segment-host-memory) below, then substitute your calculated values in the file. +:::: + ``` # kernel.shmall = _PHYS_PAGES / 2 # See Shared Memory Pages @@ -182,8 +194,8 @@ kernel.shmmax = ( _PHYS_PAGES / 2) * PAGE_SIZE To calculate the values for `kernel.shmall` and `kernel.shmmax`, run the following commands using the `getconf` command, which returns the value of an operating system variable. ``` -$ echo $(expr $(getconf _PHYS_PAGES) / 2) -$ echo $(expr $(getconf _PHYS_PAGES) / 2 \* $(getconf PAGE_SIZE)) +echo $(expr $(getconf _PHYS_PAGES) / 2) +echo $(expr $(getconf _PHYS_PAGES) / 2 \* $(getconf PAGE_SIZE)) ``` As best practice, we recommend you set the following values in the `/etc/sysctl.conf` file using calculated values. For example, a host system has 1583 GB of memory installed and returns these values: \_PHYS_PAGES = 395903676 and PAGE_SIZE = 4096. These would be the `kernel.shmall` and `kernel.shmmax` values: @@ -201,7 +213,7 @@ The `vm.overcommit_memory` Linux kernel parameter is used by the OS to determine `vm.overcommit_ratio` is the percent of RAM that is used for application processes and the remainder is reserved for the operating system. The default is 50 on Red Hat Enterprise Linux. -For `vm.overcommit_ratio` tuning and calculation recommendations with resource group-based resource management or resource queue-based resource management, refer to [Options for Configuring Segment Host Memory](../admin_guide/performance/wlmgmt_intro.md) in the *WarehousePG Administrator Guide*. +For `vm.overcommit_ratio` tuning and calculation recommendations with resource group-based resource management or resource queue-based resource management, refer to [Options for Configuring Segment Host Memory](../admin_guide/performance/wlmgmt_intro.md) in the *WarehousePG Administrator Guide*. Use the [WarehousePG memory calculator](../admin_guide/performance/mem_calc.md) to calculate a recommended `vm.overcommit_ratio` value for a host based on its physical memory, swap space, and segment count. #### Port Settings @@ -214,7 +226,7 @@ MIRROR_PORT_BASE = 7000 For information about the `gpinitsystem` cluster configuration file, see [Initializing WarehousePG](init_whpg.md). -For Azure deployments with WarehousePG avoid using port 65330; add the following line to sysctl.conf: +For Azure deployments with WarehousePG avoid using port 65330, add the following line to sysctl.conf: ``` net.ipv4.ip_local_reserved_ports=65330 @@ -438,22 +450,15 @@ WarehousePG utilizes 3 distinct MTU settings: These settings are connected, in that they should always be either the same, or close to the same, value, or otherwise in the order of WarehousePG < OS < switch for MTU size. +If the interconnect network supports jumbo frames, set the MTU to 9000 and keep `gp_max_packet_size` at its default of 8192. If the network doesn't support jumbo frames and the MTU is 1500, reduce `gp_max_packet_size` to 1472 to avoid fragmented packets. + 9000 is a common supported setting for switches, and is the recommended OS and rack switch MTU setting for your WarehousePG hosts. ### Transparent Huge Pages (THP) -Deactivate Transparent Huge Pages (THP) as it degrades WarehousePG performance. RHEL 6.0 or higher enables THP by default. One way to deactivate THP on RHEL 6.x is by adding the parameter `transparent_hugepage=never` to the kernel command in the file `/boot/grub/grub.conf`, the GRUB boot loader configuration file. This is an example kernel command from a `grub.conf` file. The command is on multiple lines for readability: - -``` -kernel /vmlinuz-2.6.18-274.3.1.el5 ro root=LABEL=/ - elevator=deadline crashkernel=128M@16M quiet console=tty1 - console=ttyS1,115200 panic=30 transparent_hugepage=never - initrd /initrd-2.6.18-274.3.1.el5.img -``` - -On systems that use `grub2`, use the system utility `grubby`. This command adds the parameter when run as root. +Deactivate Transparent Huge Pages (THP) as it degrades WarehousePG performance. On systems that use `grub2`, use the system utility `grubby`. This command adds the parameter when run as root. ``` # grubby --update-kernel=ALL --args="transparent_hugepage=never" @@ -464,7 +469,8 @@ After adding the parameter, reboot the system. This cat command checks the state of THP. The output indicates that THP is deactivated. ``` -$ cat /sys/kernel/mm/*transparent_hugepage/enabled +cat /sys/kernel/mm/*transparent_hugepage/enabled +__OUTPUT__ always [never] ``` @@ -513,10 +519,10 @@ Max Startups 10:30:200 MaxSessions 200 ``` -Restart the SSH daemon after you update `MaxStartups` and `MaxSessions`. For example, on a CentOS 6 system, run the following command as the `root` user: +Restart the SSH daemon after you update `MaxStartups` and `MaxSessions`. For example, run the following command as the `root` user: ``` -# service sshd restart +# systemctl restart sshd ``` For detailed information about SSH configuration options, refer to the SSH documentation for your Linux distribution. @@ -634,9 +640,9 @@ The `gpadmin` user must have permission to access the services and directories r The `gpadmin` user on each WarehousePG host must have an SSH key pair installed and be able to SSH from any host in the cluster to any other host in the cluster without entering a password or passphrase (called "passwordless SSH"). If you enable passwordless SSH from the coordinator host to every other host in the cluster ("1-*n* passwordless SSH"), you can use the WarehousePG `gpssh-exkeys` command-line utility later to enable passwordless SSH from every host to every other host ("*n*-*n* passwordless SSH"). -You can optionally give the `gpadmin` user sudo privilege, so that you can easily administer all hosts in the WarehousePG cluster as `gpadmin` using the `sudo`, `ssh/rsync`, and `gpssh/gpsync` commands. +You can optionally give the `gpadmin` user sudo privilege, so that you can administer all hosts in the WarehousePG cluster as `gpadmin` using the `sudo`, `ssh/rsync`, and `gpssh/gpsync` commands. -The following steps show how to set up the `gpadmin` user on a host, set a password, create an SSH key pair, and (optionally) enable sudo capability. These steps must be performed as root on every WarehousePG cluster host. (For a large WarehousePG cluster you will want to automate these steps using your system provisioning tools.) +The following steps show how to set up the `gpadmin` user on a host, set a password, create an SSH key pair, and enable passwordless sudo capability. These steps must be performed as root on every WarehousePG cluster host. (For a large WarehousePG cluster you will want to automate these steps using your system provisioning tools.) 1. Create the `gpadmin` group and user. @@ -648,19 +654,21 @@ The following steps show how to set up the `gpadmin` user on a host, set a passw # groupadd gpadmin # useradd gpadmin -r -m -g gpadmin # passwd gpadmin + __OUTPUT__ New password: Retype new password: ``` > **Note** You must have root permission to create the `gpadmin` group and user. - > **Note** Make sure the `gpadmin` user has the same user id (uid) and group id (gid) numbers on each host to prevent problems with scripts or services that use them for identity or permissions. For example, backing up WarehousePGs to some networked filesy stems or storage appliances could fail if the `gpadmin` user has different uid or gid numbers on different segment hosts. When you create the `gpadmin` group and user, you can use the `groupadd -g` option to specify a gid number and the `useradd -u` option to specify the uid number. Use the command `id gpadmin` to see the uid and gid for the `gpadmin` user on the current host. + > **Note** Make sure the `gpadmin` user has the same user id (uid) and group id (gid) numbers on each host to prevent problems with scripts or services that use them for identity or permissions. For example, backing up WarehousePGs to some networked filesystems or storage appliances could fail if the `gpadmin` user has different uid or gid numbers on different segment hosts. When you create the `gpadmin` group and user, you can use the `groupadd -g` option to specify a gid number and the `useradd -u` option to specify the uid number. Use the command `id gpadmin` to see the uid and gid for the `gpadmin` user on the current host. 2. Switch to the `gpadmin` user and generate an SSH key pair for the `gpadmin` user. ``` - $ su gpadmin - $ ssh-keygen -t rsa -b 4096 + su gpadmin + ssh-keygen -t rsa -b 4096 + __OUTPUT__ Generating public/private rsa key pair. Enter file in which to save the key (/home/gpadmin/.ssh/id_rsa): Created directory '/home/gpadmin/.ssh'. @@ -673,6 +681,10 @@ The following steps show how to set up the `gpadmin` user on a host, set a passw 3. Grant sudo access to the `gpadmin` user. + ::: info Note + This step is optional, but it's helpful, and it simplifies some procedures elsewhere in this guide, such as [Creating the Data Storage Areas](create_data_dirs.md), that run `sudo` commands on remote hosts through `gpssh`. If `gpadmin` doesn't have sudo access, you can't use `gpssh` or `gpsync` to run those commands. Because `gpssh` provides no terminal for a password prompt, the grant must let `gpadmin` run `sudo` without a password (`NOPASSWD`), as shown below, for those procedures to work. + ::: + On Red Hat or CentOS, run `visudo` and uncomment the `%wheel` group entry. ``` diff --git a/docs/whpg/7x/install_guide/create_data_dirs.md b/docs/whpg/7x/install_guide/create_data_dirs.md index 3480f73..b6472c4 100644 --- a/docs/whpg/7x/install_guide/create_data_dirs.md +++ b/docs/whpg/7x/install_guide/create_data_dirs.md @@ -19,24 +19,24 @@ A data storage area is required on the WarehousePG coordinator and standby coord The data directory location on the coordinator is different than those on the segments. The coordinator does not store any user data, only the system catalog tables and system metadata are stored on the coordinator instance, therefore you do not need to designate as much storage space as on the segments. -1. Create or choose a directory that will serve as your coordinator data storage area. This directory should have sufficient disk space for your data and be owned by the `gpadmin` user and group. For example, run the following commands as `root`: +1. Create or choose a directory that will serve as your coordinator data storage area. This directory should have sufficient disk space for your data and be owned by the `gpadmin` user and group. For example, run the following command using `sudo`: ``` - # mkdir -p /data/coordinator + sudo mkdir -p /data/coordinator ``` -2. Change ownership of this directory to the `gpadmin` user. For example: +2. Change ownership of this directory, and any parent directories you created, to the `gpadmin` user. For example: ``` - # chown gpadmin:gpadmin /data/coordinator + sudo chown gpadmin:gpadmin /data + sudo chown -R gpadmin:gpadmin /data/coordinator ``` -3. Using [gpssh](../ref_guide/utility_guide/reference/gpssh.md), create the coordinator data directory location on your standby coordinator as well. For example: +3. As the `gpadmin` user, use [gpssh](../ref_guide/utility_guide/reference/gpssh.md) to create the coordinator data directory location on your standby coordinator as well. For example: ``` - # source /usr/edb/whpg7/greenplum_path.sh - # gpssh -h scdw -e 'mkdir -p /data/coordinator' - # gpssh -h scdw -e 'chown gpadmin:gpadmin /data/coordinator' + gpssh -h scdw -e 'sudo mkdir -p /data/coordinator' + gpssh -h scdw -e 'sudo chown -R gpadmin:gpadmin /data/coordinator' ``` @@ -49,12 +49,17 @@ Data storage areas are required on the WarehousePG segment hosts for primary seg ### To create the data directory locations on all segment hosts -1. On the coordinator host, log in as `root`: +1. On the coordinator host, switch to the `gpadmin` user and source the `greenplum_path.sh` file. ``` - # su + sudo -iu gpadmin + source /usr/local/whpg/greenplum_path.sh ``` + ::: info Note + Logging in as `root` with `su` fails on hosts where root login is deactivated, such as Amazon EC2 instances. Use `sudo` for the `gpssh` commands on the remote hosts instead, so you can run them as `gpadmin`, provided `gpadmin` has `sudo` privilege as described in [Creating the WarehousePG Administrative User](config_os.md#topic23). + ::: + 2. Create a file called `hostfile_gpssh_segonly`. This file should have only one machine configured host name for each segment host. For example, if you have three segment hosts: ``` @@ -66,14 +71,17 @@ Data storage areas are required on the WarehousePG segment hosts for primary seg 3. Using [gpssh](../ref_guide/utility_guide/reference/gpssh.md), create the primary and mirror data directory locations on all segment hosts at once using the `hostfile_gpssh_segonly` file you just created. For example: ``` - # source /usr/edb/whpg7/greenplum_path.sh - # gpssh -f hostfile_gpssh_segonly -e 'mkdir -p /data1/primary' - # gpssh -f hostfile_gpssh_segonly -e 'mkdir -p /data2/primary' - # gpssh -f hostfile_gpssh_segonly -e 'mkdir -p /data1/mirror' - # gpssh -f hostfile_gpssh_segonly -e 'mkdir -p /data2/mirror' - # gpssh -f hostfile_gpssh_segonly -e 'chown -R gpadmin /data*/*' + gpssh -f hostfile_gpssh_segonly -e 'sudo mkdir -p /data1/primary' + gpssh -f hostfile_gpssh_segonly -e 'sudo mkdir -p /data2/primary' + gpssh -f hostfile_gpssh_segonly -e 'sudo mkdir -p /data1/mirror' + gpssh -f hostfile_gpssh_segonly -e 'sudo mkdir -p /data2/mirror' + gpssh -f hostfile_gpssh_segonly -e 'sudo chown -R gpadmin:gpadmin /data1 /data2' ``` + ::: warning Caution + Use `chown -R gpadmin:gpadmin /data1 /data2` rather than `chown -R gpadmin /data*/*`. The latter sets only the owner, not the group, so the primary and mirror directories stay in the `root` group. Setting both the owner and group to `gpadmin` avoids permission problems later. + ::: + ## Next Steps diff --git a/docs/whpg/7x/install_guide/init_whpg.md b/docs/whpg/7x/install_guide/init_whpg.md index ba0e607..3c9b023 100644 --- a/docs/whpg/7x/install_guide/init_whpg.md +++ b/docs/whpg/7x/install_guide/init_whpg.md @@ -43,8 +43,8 @@ These are the high-level tasks for initializing WarehousePG: When performing the following initialization tasks, you must be logged into the coordinator host as the `gpadmin` user, and to run WarehousePG utilities, you must source the `greenplum_path.sh` file to set WarehousePG environment variables. For example, if you are logged into the coordinator, run these commands. ``` -$ su - gpadmin -$ source /usr/edb/whpg7/greenplum_path.sh +su - gpadmin +source /usr/edb/whpg7/greenplum_path.sh ``` @@ -88,17 +88,31 @@ Your WarehousePG configuration file tells the [gpinitsystem](../ref_guide/utilit #### To create a gpinitsystem_config file -1. Make a copy of the `gpinitsystem_config` file to use as a starting point. For example: +1. Create the `gpconfigs` directory in the `gpadmin` home directory, if it doesn't already exist, then make a copy of the `gpinitsystem_config` file to use as a starting point. For example: ``` - $ cp $GPHOME/docs/cli_help/gpconfigs/gpinitsystem_config \ - /home/gpadmin/gpconfigs/gpinitsystem_config + mkdir -p ~/gpconfigs + cp $GPHOME/docs/cli_help/gpconfigs/gpinitsystem_config \ + ~/gpconfigs/gpinitsystem_config ``` 2. Open the file you just copied in a text editor. Set all of the required parameters according to your environment. See [gpinitsystem](../ref_guide/utility_guide/reference/gpinitsystem.md) for more information. A WarehousePG cluster must contain a coordinator instance and at *least two* segment instances (even if setting up a single node system). + The `gpinitsystem_config` file is heavily commented. These are the parameters marked **Required** in the [gpinitsystem](../ref_guide/utility_guide/reference/gpinitsystem.md) reference. All other parameters in the file, including the mirror parameters covered in step 3 below, are optional and can be left at their default values. + + | Parameter | Description | Example value | + |---|---|---| + | `SEG_PREFIX` | Prefix for segment data directories | `gpseg` | + | `PORT_BASE` | Base port for primary segments | `6000` | + | `DATA_DIRECTORY` | Primary segment data directories, one entry per segment per host | `(/data1/primary /data2/primary)` | + | `COORDINATOR_HOSTNAME` | Hostname of the coordinator host | `cdw` | + | `COORDINATOR_DIRECTORY` | Coordinator data directory | `/data/coordinator` | + | `COORDINATOR_PORT` | Coordinator port | `5432` | + | `TRUSTED_SHELL` | Shell `gpinitsystem` uses to run commands on remote hosts | `ssh` | + | `ENCODING` | Character set encoding | `UNICODE` | + The `DATA_DIRECTORY` parameter is what determines how many segments per host will be created. If your segment hosts have multiple network interfaces, and you used their interface address names in your host file, the number of segments will be evenly spread over the number of available interfaces. To specify `PORT_BASE`, review the port range specified in the `net.ipv4.ip_local_port_range` parameter in the `/etc/sysctl.conf` file. See [Recommended OS Parameters Settings](config_os.md). @@ -112,8 +126,7 @@ Your WarehousePG configuration file tells the [gpinitsystem](../ref_guide/utilit COORDINATOR_HOSTNAME=cdw COORDINATOR_DIRECTORY=/data/coordinator COORDINATOR_PORT=5432 - TRUSTED SHELL=ssh - CHECK_POINT_SEGMENTS=8 + TRUSTED_SHELL=ssh ENCODING=UNICODE ``` @@ -140,24 +153,23 @@ These steps assume you are logged in as the `gpadmin` user and have sourced the #### To run the initialization utility -1. Run the following command referencing the path and file name of your initialization configuration file (`gpinitsystem_config`) and host file (`hostfile_gpinitsystem`). For example: +1. Run the following command referencing the path and file name of your initialization configuration file (`gpinitsystem_config`) and host file (`hostfile_gpinitsystem`). Use absolute paths (or paths relative to `$HOME`, as shown here), so the command works regardless of your current working directory. For example: ``` - $ cd ~ - $ gpinitsystem -c gpconfigs/gpinitsystem_config -h gpconfigs/hostfile_gpinitsystem + gpinitsystem -c ~/gpconfigs/gpinitsystem_config -h ~/gpconfigs/hostfile_gpinitsystem ``` For a fully redundant system (with a standby coordinator and a *spread* mirror configuration) include the `-s` and `--mirror-mode=spread` options. For example: ``` - $ gpinitsystem -c gpconfigs/gpinitsystem_config -h gpconfigs/hostfile_gpinitsystem \ + gpinitsystem -c ~/gpconfigs/gpinitsystem_config -h ~/gpconfigs/hostfile_gpinitsystem \ -s --mirror-mode=spread ``` During a new cluster creation, you may use the `-O output\_configuration\_file` option to save the cluster configuration details in a file. For example: ``` - $ gpinitsystem -c gpconfigs/gpinitsystem_config -O gpconfigs/config_template + gpinitsystem -c ~/gpconfigs/gpinitsystem_config -O ~/gpconfigs/config_template ``` This output file can be edited and used at a later stage as the input file of the `-I` option, to create a new cluster or to recover from a backup. See [gpinitsystem](../ref_guide/utility_guide/reference/gpinitsystem.md) for further details. @@ -186,7 +198,15 @@ These steps assume you are logged in as the `gpadmin` user and have sourced the If the utility encounters any errors while setting up an instance, the entire process will fail, and could possibly leave you with a partially created system. Refer to the error messages and logs to determine the cause of the failure and where in the process the failure occurred. Log files are created in `~/gpAdminLogs`. -Depending on when the error occurred in the process, you may need to clean up and then try the `gpinitsystem` utility again. For example, if some segment instances were created and some failed, you may need to stop `postgres` processes and remove any utility-created data directories from your data storage area(s). A backout script is created to help with this cleanup if necessary. +The top-level log entries, such as `Failed to start segment instance database` or `Errors generated from parallel processes`, only report that a failure occurred, not the underlying cause. The actual cause is usually further down in the same log file. To find it, search the `gpinitsystem` log for the host and initialization run you want to check. The log file is appended to on every run for the day, so check the timestamps on the matched lines to make sure you're looking at the run that just failed. + +``` +grep -E 'FATAL|ERROR|error' ~/gpAdminLogs/gpinitsystem_.log | tail -20 +``` + +If the result includes `could not map anonymous shared memory: Cannot allocate memory`, the host likely doesn't have enough memory for the configured `max_connections` (default: 250 on the coordinator and 750 on segments, which is always 3x the coordinator value). This shortage is common on smaller hosts. Set a lower value, such as `COORDINATOR_MAX_CONNECT=50`, in your `gpinitsystem_config` file (or pass `-m 50` to `gpinitsystem`) and retry. + +Depending on when the error occurred in the process, you may need to clean up and then try the `gpinitsystem` utility again. For example, if some segment instances were created and some failed, you may need to stop `postgres` processes and remove any utility-created data directories from your data storage area(s). A backout script is created to help with this cleanup if necessary. Don't rerun `gpinitsystem` before you clean up. Retrying without running the backout script first fails immediately with an error such as `Coordinator host data directory already exists`. @@ -201,7 +221,7 @@ You can use this script to clean up a partially created WarehousePG cluster. Thi The following example shows how to run the backout script: ``` -$ bash ~/gpAdminLogs/backout_gpinitsystem_gpadmin_20071031_121053 +bash ~/gpAdminLogs/backout_gpinitsystem_gpadmin_20071031_121053 ``` @@ -213,8 +233,8 @@ As a best practice, configure WarehousePG and the host systems to use a known, s Use the [gpconfig](../ref_guide/utility_guide/reference/gpconfig.md) utility to show and set the WarehousePG timezone. For example, these commands show the WarehousePG timezone and set the timezone to `US/Pacific`. ``` -$ gpconfig -s TimeZone -$ gpconfig -c TimeZone -v 'US/Pacific' +gpconfig -s TimeZone +gpconfig -c TimeZone -v 'US/Pacific' ``` You must restart WarehousePG after changing the timezone. The command `gpstop -ra` restarts WarehousePG. The catalog view `pg_timezone_names` provides WarehousePG timezone information. @@ -240,7 +260,7 @@ These steps ensure that the environment variables are set for the `gpadmin` user 1. Open the `gpadmin` profile file (such as `.bashrc`) in a text editor. For example: ``` - $ vi ~/.bashrc + vi ~/.bashrc ``` 2. Add lines to this file to source the `greenplum_path.sh` file and set the `COORDINATOR_DATA_DIRECTORY` environment variable. For example: @@ -269,15 +289,15 @@ These steps ensure that the environment variables are set for the `gpadmin` user 6. After editing the profile file, source it to make the changes active. For example: ``` - $ source ~/.bashrc + source ~/.bashrc ``` 7. If you have a standby coordinator host, copy your environment file to the standby coordinator as well. For example: ``` - $ cd ~ - $ scp .bashrc :`pwd` + cd ~ + scp .bashrc :`pwd` ``` > **Note** The `.bashrc` file should not produce any output. If you wish to have a message display to users upon logging in, use the `.bash_profile` file instead. diff --git a/docs/whpg/7x/install_guide/install_whpg.md b/docs/whpg/7x/install_guide/install_whpg.md index 5cb193a..893d443 100644 --- a/docs/whpg/7x/install_guide/install_whpg.md +++ b/docs/whpg/7x/install_guide/install_whpg.md @@ -61,6 +61,17 @@ sudo yum install -y apr-devel bison bzip2-devel cmake3 flex gcc gcc-c++ \ The [README.RHEL-Rocky.bash](https://github.com/warehouse-pg/warehouse-pg/blob/main/README.RHEL-Rocky.bash) script in the repository installs the same packages and also applies the kernel, SELinux, and firewall settings described in [Configure Operating System](config_os.md). Review the script before you run it, since it changes system-wide settings. :::: +:::: info Note +If a subsequent `yum` or `dnf` command hangs waiting for the RPM lock, another process is still holding it, for example an interrupted `yum`/`dnf` whose transaction hasn't finished, or a background updater such as `packagekitd`. Identify it, then let it finish or stop it. The lock releases as soon as the process exits. + +``` +sudo fuser -v /var/lib/rpm/.rpm.lock +sudo kill +``` + +Don't delete `/var/lib/rpm/.rpm.lock`. Removing it while a process still holds it can corrupt the RPM database. +:::: + ## Building and installing WarehousePG Build WarehousePG with `configure` and `make`, then install it to a target directory. @@ -134,6 +145,33 @@ The `gpadmin` user on each WarehousePG host must be able to SSH between any two SSHPASS= sshpass -e ssh-copy-id scdw ``` + Skip the `scdw` commands if your cluster doesn't have a standby coordinator host. + + ::: info Note + `ssh-copy-id` can fail with two different errors that need different fixes. + + `ERROR: No identities found` means the `gpadmin` user has no local SSH key pair, for example because it was provisioned by a script, such as the [Example Ansible Playbook](ansible-example.md), that doesn't generate one. Generate a key pair as `gpadmin` on the coordinator, then retry `ssh-copy-id`. + + ``` + ssh-keygen -t rsa -b 4096 + ``` + + `Permission denied (publickey)` means a key pair exists, but the target host rejects password authentication, which cloud hosts such as Amazon EC2 instances often deactivate by default. In that case, copy the coordinator's public key to each host's `authorized_keys` file manually instead. On the coordinator, display the public key. + + ``` + cat /home/gpadmin/.ssh/id_rsa.pub + ``` + + Then, on each other host, create the `.ssh` directory if it doesn't already exist, append that key, and set the correct ownership and permissions. Run these commands as a user with `sudo` access, such as the default cloud image user. + + ``` + sudo install -d -m 700 -o gpadmin -g gpadmin /home/gpadmin/.ssh + echo "" | sudo tee -a /home/gpadmin/.ssh/authorized_keys + sudo chmod 600 /home/gpadmin/.ssh/authorized_keys + sudo chown -R gpadmin:gpadmin /home/gpadmin/.ssh + ``` + ::: + 4. In the `gpadmin` home directory, create a file named `hostfile_exkeys` that lists the machine-configured host names and interface addresses for every host in your WarehousePG cluster, including the coordinator, standby coordinator, and segment hosts. Make sure there are no blank lines or extra spaces. Check the `/etc/hosts` file on your systems for the correct host names to use for your environment. For example, if you have a coordinator, standby coordinator, and three segment hosts with two unbonded network interfaces per host, your file would look something like this: ``` @@ -156,6 +194,14 @@ The `gpadmin` user on each WarehousePG host must be able to SSH between any two 5. Run the `gpssh-exkeys` utility with your `hostfile_exkeys` file to enable *n*-*n* passwordless SSH for the `gpadmin` user. + `gpssh-exkeys` can fail with an error such as `No ECDSA host key is known for and you have requested strict checking` if your SSH client's strict host key checking rejects a host it doesn't yet recognize. To avoid this, populate `known_hosts` for every host in `hostfile_exkeys` first. + + ``` + ssh-keyscan -f hostfile_exkeys >> ~/.ssh/known_hosts + ``` + + Then run `gpssh-exkeys`. + ``` gpssh-exkeys -f hostfile_exkeys ``` diff --git a/docs/whpg/7x/install_guide/platform-requirements.md b/docs/whpg/7x/install_guide/platform-requirements.md index c271c06..34368da 100644 --- a/docs/whpg/7x/install_guide/platform-requirements.md +++ b/docs/whpg/7x/install_guide/platform-requirements.md @@ -232,6 +232,10 @@ The disk settings for cloud deployments are the same as on-premise with a few mo ### Amazon Web Services (AWS) +#### Networking and Security Groups + +Deploy all coordinator, standby coordinator, and segment instances in the same virtual private cloud (VPC), and use each instance's private IP address, not its public IP address, for inter-node communication and connectivity tests. A security group that only allows inbound SSH from a jump host isn't enough for the WarehousePG interconnect traffic between instances. Add a dedicated security group with a self-referencing inbound rule that allows all traffic from other instances in the same group, and apply it to every coordinator, standby coordinator, and segment instance. + #### Virtual Machine Type