Maintain the VM for a manually installed Console agent
Suggest changes
PDFs
When you manually install a Console agent, maintaining the operating system on the agent host is your (the customer's) responsibility. For example, you (the customer) should apply security updates to the operating system on the agent host by following your company's standard procedures for operating system distribution.
Apply operating system updates to the agent host
Apply OS security patches without stopping agent host services.
To maintain compatibility with supported configurations, you should prevent Docker or Podman from being upgraded during routine OS patching. You can do this by either temporarily excluding Docker or Podman during updates or by permanently configuring the package manager to skip Docker or Podman updates.
The following are examples of how to exclude Docker or Podman updates for different Linux distributions. Consult your Linux distribution's documentation for the most up-to-date instructions on how to exclude packages from updates.
sudo yum update --exclude=podman
sudo yum upgradesudo apt-mark hold docker-ce docker-ce-cli containerd.io
sudo apt update
sudo apt upgradeVM or instance type
If you create a Console agent from the Console, it deploys a VM instance in your cloud provider with a default configuration. After you create the agent, don't switch to a smaller VM instance with less CPU or RAM.
The following table lists the CPU and RAM requirements:
- CPU
-
8 cores or 8 vCPUs
- RAM
-
32 GB
Monitor the agent
The Console notifies you when the agent VM is unhealthy, including disk space, RAM, and CPU issues. Monitor these notifications in the Notifications Center within the Console or configure email notifications. Occasional increases in disk space, memory, or CPU usage are normal, but if it happens frequently, you should take steps to resolve.
For example, the Console notifies you when an agent resource (CPU, RAM, or disk space) exceeds 90% of its total capacity for 30 consecutive minutes. Afterwards, if the resource usage drops below that threshold, the notification displays as resolved (green) in the Notifications Center.
|
Work with NetApp support if you have questions about modifying your agent VM. |
| Notification | Action needed |
|---|---|
Disk space is too high |
|
CPU usage is too high |
Increase the CPU size of the agent VM in your cloud provider or on-premises, depending on where you installed it. Alternatively, create additional agents and distribute the workload across multiple agents. RAM utilization can vary based on your environment, ONTAP workloads, number of Cloud Volumes ONTAP systems, and the data services that you are using. |
RAM usage is too high |
Increase the RAM of the agent VM in your cloud provider or on-premises, depending on where you installed it. Alternatively, create additional agents and distribute the workload across multiple agents. RAM utilization can vary based on your environment, ONTAP workloads, number of Cloud Volumes ONTAP systems, and the data services that you are using. |
Stopping and starting the agent VM
If you need to, stop and start the agent VM using your cloud provider's console or standard on-premises procedures.
Connect to the Linux VM
If you need to connect to the Linux VM that the agent runs on, use the connectivity options from your cloud provider.
- AWS
-
When you create the agent instance in AWS, provide an AWS access key and secret key. You can use this key pair to SSH to the instance. Use the user name 'ubuntu' for the EC2 Linux instance. For agents created prior to May 2023, use the user name 'ec2-user'.
- Azure
-
When you create the agent VM in Azure, you specify a user name and choose to authenticate with a password or SSH public key. Use the authentication method that you chose to connect to the VM.
- Google Cloud
-
You can't specify an authentication method when you create an agent in Google Cloud. However, you can connect to the Linux VM instance using the Google Cloud Console or Google Cloud CLI (gcloud).