Editing Training 2022 Linux team/ (section)

==Training Spectra Handover with Alok. Dated 05 Nov 2022 - Tetra Support Staff - Biswajit Banerjee==

{{#ev:youtube|PGg9Iv7H-Ag|640}}

'''Video summary:''' "Spectra Handover with Alok" -- a hands-on infrastructure handover for the Spectra client's environment. Opens covering the hosting/instance access basics (credentials, control panel), then a load-balancer troubleshooting scenario: internal access to a service resolves and works correctly (verified by taking web nodes 2 and 3 down in turn and confirming the site still loads, proving the load balancer is actively distributing traffic), but external packets aren't landing -- traced to a DNS mapping issue on the global/public DNS side rather than the internal network, which the presenter walks through live without fully resolving on-camera. The bulk of the session is a detailed PCS (Pacemaker/Corosync) cluster walkthrough with DRBD-backed storage: checking `pcs status` to see which of two nodes is active/online, manually taking a node offline/standby with `pcs node standby` (and back online with `unstandby`, watching DRBD resync progress and timing, ~49 seconds observed for a small dataset), and checking DRBD sync state directly via `/proc/drbd` (states include "Connected" vs "StandAlone," and node roles "Primary"/"Secondary" -- data is only current on the Secondary if it shows fully synced with the Primary). Explains why certain cluster resources are configured with "failure ignore" -- because Pacemaker's default behavior is to fail over the service to the other node on any restart or config-triggered reload, which is undesirable for a brief, expected restart, so failure-ignore prevents an unnecessary cluster shift for these specific resources. Also covers the day-to-day support pattern the client should follow: temporarily disabling/re-enabling a specific cluster resource (`pcs resource disable/enable`) when a service appears stuck, rather than restarting the whole cluster (which can trigger a full failover); a monitoring dashboard the client was given to self-check service/sync status, with a known recurring gap where the client isn't receiving the latest alerts and needs to check manually. Closes by clarifying that the client's monitoring/NMS access needs to be verified with them directly, and to escalate immediately if the client can't see something that should be visible.