Immer schön VIRTIO als Netzwerkkarte in KVM nutzen.
Routing zwischen zwei Gästen auf dem gleichen Host.
Intel: 600 MBit/s
VIRTIO: 28 GBit/s
Beiträge von perryflynn
-
-
OPNSense
Gerade auf meinem Heim-Proxmox-KVM getestet. OPNSense kann leider nicht mit Virtio Interfaces umgehen. Daher schafft der Router "nur" 600 MBit reines Routing. Für das was ich vor hatte habe ich jetzt einfach ein normales Debian mit ein bisschen iptables genommen.
-
Stichwort Recovery System
Ja an das habe ich nicht gedacht. Nevermind.
-
Jetzt wo es AES-NI gibt wäre OPNSense als OpenVPN Gateway noch interessant.
-
So, Blog Artikel zu ZFS ist fertig:
-
in einer kommenden Version des SCP wird dieses auch ein Management für SSH-Keys unterstützen.
Aber nur bei der Neuinstallation einer VM, oder? Ansonsten wäre das ja ein Generalschlüssel.
-
Habe heute mal meinen Homeserver neu installiert und auch das ZFS neu gebaut. Ein Kumpel hat mir ein paar Tipps gegeben was ich falsch eingerichtet hatte. Nun hat sich die Performance beim Schreiben verdoppelt und beim Lesen verzehnfacht, aber bei ARC auf 16 Gigabyte begrenz zumindest noch vervierfacht.
Nachdem sich das FS ein wenig eingelebt hat gab es noch mal einen kleinen Geschwindigkeitsschub. Niedlich, oder?
-
Wird es dazu einen Blogpost von Dir geben?
Ja wenn ich mit testen fertig bin. Unter anderem habe ich atime auf dem kompletten Pool deaktiviert. Gucke gerade ob das die KVM und LXC Gäste von Proxmox stört.
-
Habe heute mal meinen Homeserver neu installiert und auch das ZFS neu gebaut. Ein Kumpel hat mir ein paar Tipps gegeben was ich falsch eingerichtet hatte. Nun hat sich die Performance beim Schreiben verdoppelt und beim Lesen verzehnfacht, aber bei ARC auf 16 Gigabyte begrenz zumindest noch vervierfacht.
Einfach krass.
-
Hatte da mal was für gebaut. In der ganz neuen Tarif Generation habe ich das aber noch nicht getestet:
-
auch Observium für euch interessant
Da guck ich mir die Community Edition mal an. Danke für den Tipp. Die gekaufte Version ist für 5 Switche glaub ich n bisschen viel.
-
Switche steuert man auch über die CLI und nicht über eine GUI
Bei dem Ding geht es ja auch nicht ums steuern, sondern um eine Übersicht. Wir sind mittlerweile dazu über gegangen, einfach die Config zu Downloaden, diese anzupassen und anschließend wieder hochzuladen. Viel einfacher als das GUI oder das CLI. Einziger negativer Effekt ist halt der Switch reboot. Aber wir nehmen so selten Änderungen vor, da ist das egal.
Übrigens ist die Übersicht auch einigermaßen Ausdruckbar, sodass man sich eine Cheat Sheet fürs Rack ausdrucken kann.
-
Wenn HP in Ihre Switche keine ordentliche GUI einbaut, muss man halt was eigenes bauen:
-
Ich kann nur sagen, dass es bei mir funktioniert wie beschrieben.
Schade.
-
Hi, Du musst das Script deployen, anderst geht das nicht.
Auch scheint das Check Plugin nicht wirklich schlau zu sein. Ich denke die einzige Möglichkeit den Check nur alle paar Stunden laufen zu lassen sind "Cached ansynchonous local checks":
http://lists.mathias-kettner.de/pipermail/chec…ber/021427.html
https://mathias-kettner.de/checkmk_localchecks.html
Siehe Punkt 6.
Schade das man das nicht in Check_MK selbst konfigurieren kann, aber es funktioniert:
CodeThe time of the next scheduled service check in 11 hCoderoot@gitlab:/usr/lib/check_mk_agent/local/43200# ls -lisah total 12K 3933094 4.0K drwxr-xr-x 2 root root 4.0K Feb 22 10:07 . 3933062 4.0K drwxr-xr-x 3 root root 4.0K Feb 22 10:07 .. 919003 4.0K -rwxr-xr-x 1 root root 2.5K Feb 21 12:03 mk_apt -
Kein Ding. Ohne einen Kollegen von mir, der Check_MK Kommerziell einsetzt, hätte ich da auch nie den Einstieg gefunden.
-
Naja, ist halt ein Tool für den Professionellen bereich. Entweder man schnürt sich eigene apt Pakete dafür oder verteilt das ganze via puppet / ansible. Außerdem erspart Dir Check_MK immer noch das einrichten der Services via manuellem Config rumgehacke.
Von wie vielen Servern reden wir hier eigentlich?
//edit
Die Scripte werden wenig bis gar nicht aktualisiert. Wenn Du dir das mal anschaust, weißt Du auch wieso. Ist alles sehr sehr simpel gehalten.
-
Ich habs jetzt mal ausprobiert.
Ich habe das mk_apt Script auf dem Server den ich Überwachen möchte unter /usr/lib/check_mk_agent/plugins/ abgelegt und das Script mit chmod a+x ausführbar gemacht.
Und siehe da:
Das funktioniert ohne das Parameter eingestellt werden müssen.
Die Ablage des Script im Ordner reicht aus.
Nach der Ablage des Scripts habe ich nur noch mal in der Service Liste einen "Full Scan" ausgeführt.
-
Zum einen muss das Plugin auf dem zu prüfenden System installiert sein (einfach das Script ins passende Verzeichnis kopieren).
Anschließend in Check_MK unter "Host & Service Parameters" eine entsprechende Regel für apt anlegen.Die Regel wird dann entweder auf alle Hosts angewendet welche sich im Ordner / Unterordner befinden oder kann mit Host Tags weiter eingeschränkt werden. Ich habe zum Beispiel ein Host Tag welches festlegt ob es ein Debian System ist oder irgendetwas anderes.//edit
Ist im Falle von mk_apt nicht notwendig.
-
Klick mal auf "5 changes" (Siehe deinen zweiten Screenshot) in WATO und lasse die mal ausführen.
Wenn man Check_MK einmal verstanden hat, ist das viel einfacher als Nagios "ohne alles". Allein schon das Check_MK das Inventar komplett selbst macht und auch das Service Monitoring entweder automatisch konfiguriert oder dies über Rulesets gemacht wird ist Mega.
