One place for hosting & domains

      Clients

      Installieren und Konfigurieren eines SNMP-Daemons und -Clients unter Ubuntu 18.04


      Der Autor hat das Internet Archive dazu ausgewählt, im Rahmen des Programms Write for DOnations eine Spende zu erhalten.

      Einführung

      Ein großer Teil der Tätigkeit eines Systemadministrators besteht darin, genaue Informationen über Ihre Server und Infrastruktur zu sammeln. Es gibt eine Reihe von Tools und Optionen, die zur Sammlung und Verarbeitung dieser Informationen dienen. Viele von ihnen basieren auf einer Technologie namens SNMP.

      SNMP steht für Simple Network Management Protokol, einfaches Netzwerkverwaltungs-Protokoll. Es ist eine Methode, mit der Server Informationen über ihren aktuellen Status austauschen können, sowie ein Kanal, über den ein Administrator vordefinierte Werte ändern kann. Während das Protokoll selbst schlank ist, kann die Struktur von Programmen, die SNMP implementieren, schnell an Komplexität zunehmen. Weitere Informationen zu den Grundlagen des SNMP-Protokolls finden Sie in unserem Artikel Eine Einführung in SNMP.

      In diesem Tutorial richten Sie die Tools zur Kommunikation mit SNMP ein. Zur Demonstration verwenden Sie zwei Ubuntu 18.04-Server. Einer enthält den SNMP-Manager, der mit dem Agenten zur Implementierung von Netzwerkgeräten spricht. Dieser wird als Manager-Server bezeichnet. Der andere Server enthält den SNMP-Agenten, der auf die Befehle des Manager-Servers reagiert. Dieser wird als Agenten-Server bezeichnet. Sie könnten sich dafür entscheiden, den Agenten auch auf dem Manager-Rechner zu installieren, aber wenn sie getrennt gehalten werden, lässt sich leichter zeigen, welche Funktionalität von jeder Komponente bereitgestellt wird.

      Voraussetzungen

      Um dieser Anleitung zu folgen, benötigen Sie:

      Schritt 1 – Installieren des SNMP-Daemons und der Dienstprogramme

      Um herauszufinden, wie SNMP auf einem System implementiert werden kann, beginnen Sie mit der Installation des Daemons und der Tools auf Ihren Ubuntu-Servern.

      Melden Sie sich von Ihrem lokalen Rechner aus als Ihr non-root user am Manager-Server an:

      • ssh your_username@manager_server_ip_address

      Aktualisieren Sie den Paketindex für den APT-Paketmanager:

      Installieren Sie anschließend die SNMP-Software:

      • sudo apt install snmp snmp-mibs-downloader

      Das Paket snmp bietet eine Sammlung von Befehlszeilen-Tools zur Ausgabe von SNMP-Anfragen an Agenten. Das Paket snmp-mibs-downloader hilft bei der Installation und Verwaltung von Management Information Base (MIB)-Dateien, die Netzwerkobjekte verfolgen.

      Öffnen Sie dann ein neues Terminal auf Ihrem lokalen Rechner und melden Sie sich bei dem Agenten-Server an:

      • ssh your_username@agent_server_ip_address

      Aktualisieren Sie auf dem Agenten-Server den Paketindex:

      Installieren Sie dann den SNMP-Daemon

      Beachten Sie, dass Sie das Paket snmp-mibs-downloader nicht benötigen, da der Agenten-Server keine MIB-Dateien verwaltet.

      Nachdem Sie nun diese Komponenten installiert haben, konfigurieren Sie Ihren Manager-Server.

      Schritt 2 — Konfigurieren des SNMP Manager-Servers

      Wie bereits erwähnt, wird der Großteil der Arbeit auf dem Agenten-Server stattfinden, sodass Ihre Konfiguration auf dem Manager-Server weniger aufwendig ist. Um sicherzustellen, dass SNMP-Tools die von Ihnen installierten zusätzlichen MIB-Daten verwenden können, müssen Sie nur eine Datei ändern.

      Öffnen Sie auf Ihrem Manager-Server die Datei /etc/snmp/snmp.conf in Ihrem Texteditor mit sudo-Berechtigungen. Dieses Tutorial verwendet nano:

      • sudo nano /etc/snmp/snmp.conf

      In dieser Datei gibt es einige Kommentare und eine einzige unkommentierte Zeile. Damit der Manager die MIB-Dateien importieren kann, kommentieren Sie die Zeile mibs : aus:

      /etc/snmp/snmp.conf

      # As the snmp packages come without MIB files due to license reasons, loading
      # of MIBs is disabled by default. If you added the MIBs you can reenable
      # loading them by commenting out the following line.
      #mibs :
      

      Speichern und schließen Sie snmp.conf, indem Sie STRG+X drücken, gefolgt von Y und dann der Eingabetaste, wenn Sie nano verwenden.

      Die Konfiguration des Manager-Servers ist nun abgeschlossen, aber Sie müssen diesen Server immer noch verwenden, um bei der Konfiguration Ihres Agenten-Servers zu helfen, was Sie im nächsten Schritt tun werden.

      Schritt 2 — Konfigurieren des SNMP Agenten-Servers

      Als echtes Client-Server-System verfügt der Agenten-Server über keine der externen Tools, die zur Konfiguration seiner eigenen SNMP-Einrichtung erforderlich sind. Sie können einige Konfigurationsdateien ändern, um einige Änderungen vorzunehmen, aber die meisten Änderungen, die Sie vornehmen müssen, werden durch eine Verbindung zu Ihrem Agenten-Server von Ihrem Management-Server aus vorgenommen.

      In diesem Tutorial verwenden Sie Version 3 des SNMP-Protokolls. Im Gegensatz zu SNMPv1 und v2 enthält bei SNMPv3 jede Nachricht Sicherheitsparameter, die verschlüsselt sind. In diesem Schritt konfigurieren Sie die SNMPv3-Authentifizierungs- und Zugriffskontrollregeln.

      Um zu beginnen, öffnen Sie auf Ihrem Agenten-Server die Konfigurationsdatei des Daemons mit sudo-Berechtigungen:

      • sudo nano /etc/snmp/snmpd.conf

      Sie müssen einige Änderungen darin vornehmen. Diese werden hauptsächlich für das Bootstrapping Ihrer Konfiguration verwendet, damit Sie diese von Ihrem anderen Server aus verwalten können.

      Zuerst müssen Sie die Anweisung agentAddress ändern. Momentan ist sie so eingestellt, dass sie nur vom lokalen Rechner ausgehende Verbindungen zulässt. Sie müssen die aktuelle Zeile auskommentieren und die Zeile darunter, die alle Verbindungen ermöglicht, entkommentieren.

      /etc/snmp/snmpd.conf

      #  Listen for connections from the local system only
      #agentAddress  udp:127.0.0.1:161
      #  Listen for connections on all interfaces (both IPv4 *and* IPv6)
      agentAddress udp:161,udp6:[::1]:161
      

      Anmerkung: Da das Zulassen aller Verbindungen auf diese Art keine optimale Sicherheitspraxis ist, empfiehlt es sich, diese bald wieder zu sperren, nachdem das Bootstrapping abgeschlossen ist.

      Als Nächstes fügen Sie vorübergehend eine Zeile createUser ein. Diese Anweisungen werden normalerweise nicht in dieser Datei aufbewahrt; Sie werden sie in Kürze wieder entfernen.

      Der Benutzer, den Sie erstellen, wird als bootstrap bezeichnet und wird als Vorlage verwendet, in der Sie Ihren ersten tatsächlichen Benutzer erstellen. Die SNMP-Pakete führen dies durch das Klonen der Eigenschaften des Benutzers aus.

      Wenn Sie einen neuen Benutzer definieren, müssen Sie den Authentifizierungstyp (MD5 oder SHA) angeben und eine Passphrase mit mindestens acht Zeichen bereitstellen. Wenn Sie vorhaben, die Übertragung zu verschlüsseln, wie Sie es in diesem Tutorial tun werden, müssen Sie auch das Datenschutzprotokoll (DES oder AES) und optional eine Datenschutzprotokoll-Passphrase angeben. Wenn keine Passphrase für das Datenschutzprotokoll angegeben wird, wird die Authentifizierungs-Passphrase auch für das Datenschutzprotokoll verwendet.

      Fügen Sie diese Zeile createUser am Ende der Datei hinzu:

      /etc/snmp/snmpd.conf

      ...
      createUser bootstrap MD5 temp_password DES
      

      Nachdem Sie nun einen neuen Benutzer angegeben haben, können Sie die Zugriffsebene einrichten, die dieser Benutzer haben wird. In diesem Tutorial richten Sie diesen für Ihren Benutzer bootstrap als auch für den neuen Benutzer demo ein, den Sie anlegen werden. Sie werden Ihnen Lese- und Schreibberechtigungen erteilen, indem Sie die Anweisung rwuser verwenden (die Alternative ist rouser für den Nur-Lese-Zugriff).

      Sie werden auch die Verwendung der Verschlüsselung erzwingen, indem Sie nach dem Benutzer priv angeben. Wenn Sie den Benutzer auf einen bestimmten Teil der MIB beschränken möchten, können Sie am Ende der Zeile den höchsten Objektidentifikator (OID) angeben, auf den der Benutzer Zugriff haben soll.

      Für die Zwecke dieses Tutorials werden Ihre beiden Zeilen wie folgt aussehen:

      /etc/snmp/snmpd.conf

      ...
      rwuser bootstrap priv
      rwuser demo priv
      

      Wenn Sie mit diesen Änderungen fertig sind, speichern und schließen Sie die Datei.

      Um diese Änderungen zu implementieren, starten Sie den Dienst snmpd auf Ihrem Agenten-Server neu:

      • sudo systemctl restart snmpd

      Der SNMP-Daemon horcht auf Port :161 auf Verbindungen. Konfigurieren Sie UFW, um Verbindungen vom Manager-Server zu diesem Port zu erlauben:

      • sudo ufw allow from manager_server_ip_address to any port 161

      Mehr über UFW erfahren Sie in Einrichten einer Firewall mit UFW unter Ubuntu 18.04.

      Nachdem nun der Agenten-Server konfiguriert ist, können Sie sich über den Manager-Server mit Ihrem Agenten-Server verbinden, um die Verbindung zu überprüfen.

      Schritt 4 — Verifizieren der Authentifizierung zum Agenten-Server

      In diesem Schritt führen Sie einen Test durch, um sicherzustellen, dass Sie mit Ihrem Konto bootstrap eine Verbindung zum Agenten-Server herstellen können. Zuvor wird in diesem Tutorial jedoch ein wenig über die allgemeine Struktur des Sendens eines SNMP-Befehls gesprochen.

      Wenn Sie die in dem Paket snmp (die net-snmp Software Suite) enthaltenen Tools verwenden, gibt es einige Muster, wie Sie die Befehle aufrufen müssen. Als Erstes müssen Sie sich bei dem SNMP-Daemon authentifizieren, mit dem Sie kommunizieren möchten. Dazu müssen in der Regel einige Informationen bereitgestellt werden. Die häufigsten sind die folgenden:

      • -v: Dieses Flag wird zur Angabe der Version des SNMP-Protokolls verwendet, die Sie verwenden möchten. Dieses Tutorial verwendet v3.
      • -c: Dieses Flag wird verwendet, wenn Sie SNMP v1 oder v2-ähnliche Community-Strings zur Authentifizierung verwenden. Da Sie eine benutzerbasierte Authentifizierung im Stil von v3 verwenden, brauchen Sie dies nicht zu tun.
      • -u: Dieser Parameter wird verwendet, um den Benutzernamen anzugeben, als den Sie sich authentifizieren möchten. Um mit SNMP etwas zu lesen oder zu ändern, müssen Sie sich mit einem bekannten Benutzernamen authentifizieren.
      • -l: Dieser Parameter wird verwendet, um die Sicherheitsebene anzugeben, mit der Sie sich verbinden. Die möglichen Werte sind noAuthNoPriv für keine Authentifizierung und keine Verschlüsselung, authNoPriv für die Authentifizierung aber keine Verschlüsselung sowie authPriv für die Authentifizierung und Verschlüsselung. Der Benutzername, den Sie verwenden, muss so konfiguriert sein, dass er auf der von Ihnen angegebenen Sicherheitsstufe funktioniert, sonst wird die Authentifizierung nicht erfolgreich sein.
      • -a: Dieser Parameter wird verwendet, um das verwendete Authentifizierungsprotokoll anzugeben. Die möglichen Werte sind MD5 oder SHA. Dies muss mit den Informationen übereinstimmen, die beim Anlegen des Benutzers angegeben wurden.
      • -x: Dieser Parameter wird verwendet, um das verwendete Verschlüsselungsprotokoll anzugeben. Die möglichen Werte sind DES oder AES. Dies muss mit den Informationen übereinstimmen, die beim Anlegen des Benutzers angegeben wurden. Dies ist immer dann erforderlich, wenn die Berechtigungsspezifikation des Benutzers priv dahinter enthält, wodurch die Verschlüsselung obligatorisch wird.
      • -A: Wird verwendet, um die Authentifizierungs-Passphrase anzugeben, die bei der Erstellung des Benutzers angegeben wurde.
      • -X: Dies ist die Verschlüsselungs-Passphrase, die bei der Erstellung des Benutzers angegeben wurde. Wenn keine Passphrase aber ein Verschlüsselungsalgorithmus angegeben wurde, wird die Authentifizierungs-Passphrase verwendet. Dies ist erforderlich, wenn der Parameter -x angegeben wird oder wenn die Berechtigungsspezifikation eines Benutzers ein priv dahinter hat, das eine Verschlüsselung erfordert.

      Anhand dieser Informationen können Sie Ihre Befehle erstellen. In Anbetracht der Art und Weise, wie Sie Ihren Benutzer bootstrap einrichten, werden die Befehle, die Sie mit diesem Konto verwenden, wie folgt aussehen:

      snmp_command -u bootstrap -l authPriv -a MD5 -x DES -A temp_password -X temp_password remote_host snmp_sub_command_or_options
      

      Testen Sie von Ihrem Manager-Server aus, um sicherzustellen, dass Ihr Konto bootstrap verfügbar ist. Geben Sie Folgendes ein, um die Systeminformationen für den Agenten-Server anzuzeigen:

      • snmpget -u bootstrap -l authPriv -a MD5 -x DES -A temp_password -X temp_password agent_server_ip_address 1.3.6.1.2.1.1.1.0

      Die Zeichenfolge 1.3.6.1.2.1.1.1.0 ist die OID, die für die Anzeige von Systeminformationen verantwortlich ist. Sie gibt die Ausgabe von uname -a auf dem Remote-System zurück.

      Dadurch erhalten Sie folgenden Output:

      Output

      SNMPv2-MIB::sysDescr.0 = STRING: Linux agent 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC 2019 x86_64

      Nachdem Sie nun überprüft haben, dass Sie sich auf dem Server, auf dem der SNMP-Daemon ausgeführt wird, authentifizieren können, können Sie mit der Erstellung Ihres regulären Benutzerkontos fortfahren.

      Schritt 5 — Einrichten des regulären Benutzerkontos

      Obwohl Sie die Berechtigungen für das Benutzerkonto demo in der Datei snmpd.conf angegeben haben, haben Sie diesen Benutzer noch nicht wirklich erstellt. In diesem Schritt verwenden Sie den Benutzer bootstrap als Vorlage für Ihren neuen Benutzer. Sie werden dies mit dem Tool snmpusm tun, das für die Benutzerverwaltung verwendet wird.

      Auf dem Manager-Server können Sie den Benutzer aus der Vorlage mithilfe des Tools snmpusm und der folgenden allgemeinen Syntax anlegen.

      snmpusm authentication_info agent_server_ip_address create new_user existing_user
      

      Mit dem, was Sie über die zu übermittelnden Authentifizierungs-Flags wissen, und unter Nutzung des bereits vorhandenen Benutzerkontos (bootstrap) können Sie einen Benutzer erstellen, der zu den bereits definierten Benutzerrechten passt (demo).

      Der Befehl sieht wie folgt aus:

      • snmpusm -u bootstrap -l authPriv -a MD5 -x DES -A temp_password -X temp_password agent_server_ip_address create demo bootstrap

      Sie erhalten die folgende Meldung:

      Output

      User successfully created.

      Sie haben nun einen voll funktionsfähigen Benutzer namens demo auf Ihrem Agenten-Server. Es verwendet jedoch nach wie vor die gleichen Authentifizierungsinformationen wie das Konto bootstrap. Um die Sicherheit zu erhöhen, können Sie das Passwort ändern. Dieses Mal verwenden Sie das Konto demo zur Authentifizierung. Denken Sie daran, dass Passwörter mindestens acht Zeichen lang sein müssen:

      • snmpusm -u demo -l authPriv -a MD5 -x DES -A temp_password -X temp_password agent_server_ip_address passwd temp_password new_password

      Sie erhalten die folgende Meldung zurück:

      Output

      SNMPv3 Key(s) successfully changed.

      Sie können Ihre neuen Berechtigungsnachweise und Ihr Passwort testen, indem Sie den Agenten-Server fragen, wie lange der SNMP-Dienst bereits ausgeführt wird. Sie verwenden den Befehl snmpget, um einen einzelnen Wert von dem Agenten-Server zu erhalten.

      Nutzen Sie diesmal die von Ihnen heruntergeladenen zusätzlichen MIB-Definitionen, um den Wert nach Namen anstelle der numerischen ID von OID zu erfragen.

      • snmpget -u demo -l authPriv -a MD5 -x DES -A new_password -X new_password agent_server_ip_address sysUpTime.0

      Sie erhalten einen Wert zurück, der das letzte Mal repräsentiert, als der entfernte SNMP-Daemon neu gestartet wurde:

      Output

      DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (53309) 0:08:53.09

      Sie haben nun ein funktionierendes Benutzerkonto namens demo. Im nächsten Schritt vereinfachen Sie das Arbeiten mit SNMP-Befehlen durch die Konfiguration des Client.

      Schritt 6 – Erstellen einer Client-Konfigurationsdatei

      Sie haben zu diesem Punkt wahrscheinlich bemerkt, dass die Authentifizierungsdetails für alle Ihre SNMP-Befehle bei jeder Anfrage ziemlich statisch sind. Anstatt diese jedes Mal einzugeben, können Sie eine clientseitige Konfigurationsdatei erstellen, die die Berechtigungsnachweise enthält, mit denen Sie sich verbinden.

      Die Client-Konfigurationsdatei kann an zwei verschiedenen Stellen abgelegt werden, je nachdem, wie weit Sie sie freigeben möchten.

      Wenn Sie Ihre Anmeldedaten für jeden gültigen Benutzer auf Ihrem Management-Rechner freigeben möchten, können Sie Ihre Konfigurationsdetails in der globalen Datei snmp.conf auf dem Manager-Server ablegen. Sie müssten diese Datei mit sudo-Berechtigungen öffnen:

      • sudo nano /etc/snmp/snmp.conf

      Wenn Sie jedoch die Berechtigungsnachweise für die Authentifizierung nur für Ihren Benutzer definieren möchten, können Sie ein verstecktes Verzeichnis .snmp im Stammverzeichnis Ihres Benutzers auf dem Manager-Server erstellen und die Datei dort anlegen:

      • mkdir ~/.snmp
      • nano ~/.snmp/snmp.conf

      Unabhängig von Ihrer Entscheidung, wo Sie Ihre Konfiguration ablegen, bleibt der Inhalt derselbe.

      Die Befehle, die Sie zur Authentifizierung verwenden, sind in der folgenden Tabelle aufgeführt. In der rechten Spalte sehen Sie die Namen der Anweisungen, die zur Erstellung dieser Konfigurationsdetails innerhalb der Datei snmp.conf verwendet werden:

      Befehls-FlagBeschreibungÜbersetzte snmp.conf-Anweisung
      -u usernameDer SNMPv3-Benutzername, mit dem sich authentifiziert wird.defSecurityName username
      -l authPrivDie Sicherheitsstufe, mit der sich authentifiziert wird.defSecurityLevel authPriv
      -a MD5Das zu verwendende Authentifizierungsprotokoll.defAuthType MD5
      -x DESDas zu verwendende Datenschutz (Verschlüsselungs)-Protokoll.defPrivType DES
      -A passphraseDie Authentifizierungs-Passphrase für den angegebenen Benutzernamen.defAuthPassphrase passphrase
      -X passphraseDie Datenschutz-Passphrase aus dem angegebenen Benutzernamen.defPrivPassphrase passphrase

      Anhand dieser Informationen können Sie eine entsprechende Datei snmp.conf erstellen. Für diesen Leitfaden sieht sie wie folgt aus:

      snmp.conf

      defSecurityName demo
      defSecurityLevel authPriv
      defAuthType MD5
      defPrivType DES
      defAuthPassphrase new_password
      defPrivPassphrase new_password
      

      Wenn Sie dies abgeschlossen haben, speichern und schließen Sie die Datei.

      Sie können nun Befehle ausgeben, ohne die Authentifizierungsdetails anzugeben. Sie benötigen nur den SNMP-Befehl, den Host und die Befehlsargumente.

      Anstatt einzugeben:

      • snmpget -u demo -l authPriv -a MD5 -x DES -A new_password -X new_password agent_server_ip_address sysUpTime.0

      Können Sie eingeben:

      • snmpget agent_server_ip_address sysUpTime.0

      Wie Sie sehen können, reduziert sich dadurch die Menge der Informationen, die Sie in jeder Anfrage bereitstellen müssen. Als Nächstes entfernen Sie das Konto bootstrap, um die Netzwerksicherheit zu erhöhen.

      Schritt 7 – Entfernen des Kontos Bootstrap

      Nachdem Ihr reguläres Konto nun korrekt konfiguriert ist, können Sie das unsichere Konto bootstrap entfernen.

      Öffnen Sie auf Ihrem Agenten-Server erneut die Datei /etc/snmp/snmpd.conf mit sudo-Berechtigungen.

      • sudo nano /etc/snmp/snmpd.conf

      Suchen und kommentieren (oder entfernen) Sie beide Zeilen aus, die Sie zuvor hinzugefügt haben und die auf den Benutzer bootstrap verweisen:

      /etc/snmp/snmpd.conf

      ...
      #createUser bootstrap MD5 temp_password DES
      #rwuser bootstrap priv
      ...
      

      Speichern und schließen Sie die Datei.

      Starten Sie nun den SNMP-Daemon neu:

      • sudo systemctl restart snmpd

      Damit wird die Empfehlung erfüllt, keine Anweisung createUser in der normalen Datei snmpd.conf zu haben. Hierdurch werden auch Berechtigungen von dem temporären Benutzer entfernt.

      Wenn Sie den Benutzer bootstrap vollständig aus der usmUserTable entfernen möchten, können Sie dies tun, indem Sie diesen Befehl vom Manager-Server aus erteilen:

      • snmpusm agent_server_ip_address delete bootstrap

      Sie erhalten die folgende Antwort:

      Output

      User successfully deleted.

      Zusammenfassung

      Zu diesem Zeitpunkt haben Sie eine vollständig konfigurierte Client-Server-Einrichtung, die über das SNMP-Protokoll sicher kommunizieren kann. Sie können nun zusätzliche Daemons auf anderen Hosts hinzufügen und den Kontozugriff über Ihre gesamte Infrastruktur konfigurieren.

      Für weitere Studien können Sie unser Tutorial Verwenden der Net-SNMP Tool-Suite zur Verwaltung und Überwachung von Servern verwenden, um mehr über SNMP-Tools und ihre Verwendung zum Abrufen von Werten nacheinander oder in großen Mengen sowie zum Ändern von Daten zu erfahren.



      Source link

      How To Manage Replicas and Clients in Redis


      Introduction

      Redis is an open-source, in-memory key-value data store. One of its most sought-after features is its support for replication: any Redis server can replicate its data to any number of replicas, allowing for high read scalability and strong data redundancy. Additionally, Redis was designed to allow many clients (up to 10000, by default) to connect and interact with data, making it a good choice for cases where many users need access to the same dataset.

      This tutorial goes over the commands used to manage Redis clients and replicas.

      How To Use This Guide
      This guide is written as a cheat sheet with self-contained examples. We encourage you to jump to any section that is relevant to the task you’re trying to complete.

      The commands shown in this guide were tested on an Ubuntu 18.04 server running Redis version 4.0.9. To set up a similar environment, you can follow Step 1 of our guide on How To Install and Secure Redis on Ubuntu 18.04. We will demonstrate how these commands behave by running them with redis-cli, the Redis command line interface. Note that if you’re using a different Redis interface — Redli, for example — the exact output of certain commands may differ.

      Alternatively, you could provision a managed Redis database instance to test these commands, but note that depending on the level of control allowed by your database provider, some commands in this guide may not work as described. To provision a DigitalOcean Managed Database, follow our Managed Databases product documentation. Then, you must either install Redli or set up a TLS tunnel in order to connect to the Managed Database over TLS.

      Note: The Redis project uses the terms “master” and “slave” in its documentation and in various commands to identify different roles in replication, though the project’s contributors are taking steps to change this language in cases where it doesn’t cause compatibility issues. DigitalOcean generally prefers to use the alternative terms “primary” and “replica”.

      This guide will default to “primary” and “replica” whenever possible, but note that there are a few instances where the terms “master” and “slave” unavoidably come up.

      Managing Replicas

      One of Redis’s most distinguishing features is its built-in replication. When using replication, Redis creates exact copies of the primary instance. These secondary instances reconnect to the primary any time their connections break and will always aim to remain an exact copy of the primary.

      If you’re not sure whether the Redis instance you’re currently connected to is a primary instance or a replica, you can check by running the role command:

      This command will return either master or slave, or potentially sentinel if you’re using Redis Sentinel.

      To designate a Redis instance as a replica of another instance on the fly, run the replicaof command. This command takes the intended primary server’s hostname or IP address and port as arguments:

      • replicaof hostname_or_IP port

      If the server was already a replica of another primary, it will stop replicating the old server and immediately start synchronizing with the new one. It will also discard the old dataset.

      To promote a replica back to being a primary, run the following replicaof command:

      This will stop the instance from replicating the primary server, but will not discard the dataset it has already replicated. This syntax is useful in cases where the original primary fails. After running replicaof no one on a replica of the failed primary, the former replica can be used as the new primary and have its own replicas as a failsafe.

      Note: Prior to version 5.0.0, Redis instead included a version of this command named slaveof.

      Managing Clients

      A client is any machine or software that connects to a server in order to access a service. Redis comes with several commands that help with tracking and managing client connections.

      The client list command returns a set of human-readable information about current client connections:

      Output

      "id=18165 addr=[2001:db8:0:0::12]:47460 fd=7 name=jerry age=72756 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping id=18166 addr=[2001:db8:0:1::12]:47466 fd=8 name= age=72755 idle=5 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=info id=19381 addr=[2001:db8:0:2::12]:54910 fd=9 name= age=9 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=26 qbuf-free=32742 obl=0 oll=0 omem=0 events=r cmd=client "

      Here is what each of these fields mean:

      • id: a unique 64-bit client ID
      • name: the name of the client connection, as defined by a prior client setname command
      • addr: the address and port from which the client is connecting
      • fd: the file descriptor that corresponds to the socket over which the client is connecting
      • age: the total duration of the client connection, in seconds
      • flags: a set of one or more single-character flags that provide more granular detail about the clients; see the client list command documentation for more details
      • db: the current database ID number that the client is connected to (can be from 0 to 15)
      • sub: the number of channels the client is subscribed to
      • psub: the number of the client’s pattern-matching subscriptions
      • mutli: the number of commands the client has queued in a transaction (will show -1 if the client hasn’t begun a transaction or 0 if it has only started a transaction and not queued any commands)
      • qbuf: the client’s query buffer length, with 0 meaning it has no pending queries
      • qbuf-free: the amount of free space in the client’s query buffer, with 0 meaning that the query buffer is full
      • obl: the client’s output buffer length
      • oll: the length of the client’s output list, where replies are queued when its buffer is full
      • omem: the memory used by the client’s output buffer
      • events: the client’s file descriptor events, these can be r for “readable”, w for “writable,” or both
      • cmd: the last command run by the client

      Setting client names is useful for debugging connection leaks in whatever application is using Redis. Every new connection starts without an assigned name, but client setname can be used to create one for the current client connection. There’s no limit to how long client names can be, although Redis usually limits string lengths to 512 MB. Note, though, that client names cannot include spaces:

      To retrieve the name of a client connection, use the client getname command:

      Output

      "elaine"

      To retrieve a client’s connection ID, use the client id command:

      Output

      (integer) "19492"

      Redis client IDs are never repeated and are monotonically incremental. This means that if one client has an ID greater than another, then it was established at a later time.

      Blocking Clients and Closing Client Connections

      Replication systems are typically described as being either synchronous or asynchronous. In synchronous replication, whenever a client adds or changes data it must receive some kind of acknowledgement from a certain number of replicas for the change to register as having been committed. This helps to prevent nodes from having data conflicts but it comes at a cost of latency, since the client must wait to perform another operation until it has heard back from a certain number of replicas.

      In asynchronous replication, on the other hand, the client sees a confirmation that the operation is finished as soon as the data is written to local storage. There can, however, be a lag between this and when the replicas actually write the data. If one of the replicas fails before it can write the change, that write will be lost forever. So while asynchronous replication allows clients to continue performing operations without the latency caused by waiting for replicas, it can lead to data conflicts between nodes and may require extra work on the part of the database administrator to resolve those conflicts.

      Because of its focus on performance and low latency, Redis implements asynchronous replication by default. However, you can simulate synchronous replication with the wait command. wait blocks the current client connection for a specified amount of time (in milliseconds) until all the previous write commands are successfully transferred and accepted by a specified number of replicas. This command uses the following syntax:

      • wait number_of_replicas number_of_milliseconds

      For example, if you want to block your client connection until all the previous writes are registered by at least 3 replicas within a 30 millisecond timeout, your wait syntax would look like this:

      The wait command returns an integer representing the number of replicas that acknowledged the write commands, even if not every replica does so:

      Output

      2

      To unblock a client connection that has been previously blocked, whether from a wait, brpop, or xread command, you can run a client unblock command with the following syntax:

      To temporarily suspend every client currently connected to the Redis server, you can use the client pause command. This is useful in cases where you need to make changes to your Redis setup in a controlled way. For example, if you’re promoting one of your replicas to be the primary instance, you might pause every client beforehand so you can promote the replica and have the clients connect to it as the new primary without losing any write operations in the process.

      The client pause command requires you to specify the amount of time (in milliseconds) you’d like to suspend the clients. The following example will suspend all clients for one second:

      The client kill syntax allows you to close a single connection or a set of specific connections based on a number of different filters. The syntax looks like this:

      • client kill filter_1 value_1 ... filter_n value_n

      In Redis versions 2.8.12 and later, the following filters are available:

      • addr: allows you to close a client connection from a specified IP address and port
      • client-id: allows you to close a client connection based on its unique ID field
      • type: closes every client of a given type, which can be either normal, master, slave, or pubsub
      • skipme: the value options for this filter are yes and no:
        • if no is specified, the client calling the client kill command will not get skipped, and will be killed if the other filters apply to it
        • if yes is specified, the client running the command will be skipped and the kill command will have no effect on the client. skipme is always yes by default

      Conclusion

      This guide details a number of commands used to manage Redis clients and replicas. If there are other related commands, arguments, or procedures you’d like to see outlined in this guide, please ask or make suggestions in the comments below.

      For more information on Redis commands, see our tutorial series on How to Manage a Redis Database.



      Source link