zittersplitter.de

Folgende Konfig reicht aus

 

hc44:~ # cat /etc/chrony.conf|grep -v ‘^#’

pool pool.ntp.org iburst

driftfile /var/lib/chrony/drift

makestep 1.0 3

rtcsync

logdir /var/log/chrony

include /etc/chrony.d/*.conf

 

/etc/chrony.d/  ist leer

 

nun:

 

systemctl enable chronyd

systemctl start chronyd

 

danach sieht man im timedatectl automatisch folgendes :

 

Vorher:

 

hhc44:~ # timedatectl

      Local time: Tue 2021-04-20 14:27:57 CEST

  Universal time: Tue 2021-04-20 12:27:57 UTC

        RTC time: Tue 2021-04-20 12:27:57

       Time zone: Europe/Berlin (CEST, +0200)

Network time on: no

NTP synchronized: no

RTC in local TZ: no

 

Danach:

 

NTP synchronized: yes

 

 Das hatte mich bei den anderen Systemen verwirrt, da man das lt. doku  mittels

timedatectl set-ntp true  auch erreichen kann, dann ist aber der

systemd-timesyncd involviert mit eigener Konfig.

Aber der ist inaktiv.

 

hhc44:~ # systemctl status systemd-timesyncd

• systemd-timesyncd.service – Network Time Synchronization

   Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; disabled;>

   Active: inactive (dead)

     Docs: man:systemd-timesyncd.service(8)

 

Fazit: wenn man chronyd startet, ist alles gut ;-)

 

Ein paar Abfragen:

 

hhc44:~ # chronyc -a sources

210 Number of sources = 4

MS Name/IP address         Stratum Poll Reach LastRx Last sample

===============================================================================

 

hhc44:~ # chronyc -a activity

200 OK

4 sources online

0 sources offline

0 sources doing burst (return to online)

0 sources doing burst (return to offline)

0 sources with unknown address

 

hhc44:~ # chronyc -a tracking

Reference ID    : 81468424 (stratum2-3.NTP.TechFak.NET)

Stratum         : 3

Ref time (UTC)  : Tue Apr 20 12:33:34 2021

System time     : 0.000102860 seconds fast of NTP time

Last offset     : -0.000005700 seconds

RMS offset      : 0.000900322 seconds

Frequency       : 25.559 ppm slow

Residual freq   : -0.002 ppm

Skew            : 0.035 ppm

Root delay      : 0.007883033 seconds

Root dispersion : 0.001170535 seconds

Update interval : 130.0 seconds

Leap status     : Normal

things I always search for… 

 

root@nim-tsm# lsdev | grep hdisk

hdisk0 Available 06-08-02 MPIO NetApp FCP Default PCM Disk

hdisk1 Available 06-08-02 MPIO NetApp FCP Default PCM Disk

hdisk2 Available 09-08-00-3,0 16 Bit LVD SCSI Disk Drive

hdisk3 Available 09-08-00-4,0 16 Bit LVD SCSI Disk Drive

 

 

 

root@nim-tsm# lsattr -El hdisk0 |grep lun_id

lun_id 0x13000000000000 Logical Unit Number ID False

 

 

root@nim-tsm:/root # lsattr -El hdisk0
PCM PCM/friend/vscsi             Path Control Module False
algorithm fail_over                    Algorithm True
hcheck_cmd test_unit_rdy      Health Check Command True+
hcheck_interval 0                       Health Check Interval True+
hcheck_mode nonactive            Health Check Mode True+
max_transfer 0x40000              Maximum TRANSFER Size True
pvid 00c9b63095a791ee0000000000000000 Physical volume identifier False
queue_depth 3                             Queue DEPTH True+
reserve_policy no_reserve       Reserve Policy True+
root@nim-tsm:/root #

 

 

Wir golfen seit ein paar Wochen und ich dachte, ich bereichere das Interwebz nun mal mit einem ersten Golf-Posting =) 

 

Ein toller Tipp unseres Pro, um zuverlässiger mit dem Putter gewisse Längen zu erzielen ist folgender:

 

 

• Wir benötigen zwei Linien.
• Die vordere, gedachte, Linie gilt als Minimum, die hintere Linie als Maximum.
• Das kann man an Fixpunkten wie der Fahne oder einem abgelegten Schläger festmachen.
• Nun spielt man aus einer gewohnten Distanz den ersten Ball über die Minimum-Linie.
• Der folgende Ball muss den ersten Ball überholen, darf aber nicht das Maximum überschreiten.
• Der dritte Ball muss somit den zweiten Ball überholen und darf ebenfalls nicht das Maximum überschreiten.

Wenn der ganze Spaß geklappt hat, erhöht man die Distanz um ca 1 Meter.

Sollte ein Ball danebengehen, fängt man die gleiche Distanz komplett von vorne an, bis es klappt.

 

Klingt einfach, kann einen aber in den Wahnsinn treiben ;)

Wir haben damit schnell gute Ergebnisse erzielt und 

 

…manche tun aber auch echt nichts dafür, um das Klischee des tiefarroganten Consolenhelden abzubauen…

Wenn ich auf ner frisch deployten Testbox – fucking noch eins – irgendwas mit ROOT ausführen will, dann ist das meine Entscheidung und da will ich nicht von so nem Typen vollgelabert werden, der die aktuell vorherrschenden Situation nicht kennt, aber seine Welt für die einzig Richtige hält…

 

 

Frei nach Terry Lambert:

“It is not UNIX’s job to stop you from shooting your foot. If you so choose to do so, then it is UNIX’s job to deliver Mr. Bullet to Mr Foot in the most efficient way it knows.”

Die Load eines Linux Systems zeigt die Auslastung einer CPU an.

Die drei Werte der “load averange” sind Durchschnittswerte auf eine, fünf und zehn Minuten. Somit kann die echte Last des Systems auf einen Blick erkannt werden, da der aktuelle Wert allein nicht wirklich aussagekräftig ist und starken Schwankungen unterliegt.

Wenn wir ein Single-Core System betrachten, dann zeigt sich eine Load wie folgt:

Wie man sieht ist ein zur Hälfte ausgelasteter Core mit 0,5 angezeigt. Eine Load von 1 ist immer noch ein Zustand von “OK”, da dies bedeutet, dass das was reinkommt auch direkt bearbeitet werden kann und die CPU mit einer 100%igen Auslastung fährt, also nahezu im Idealzustand der nutzbaren Performance ist.

Eine Load von über 1 zeigt in einem Single-Core System, dass es zu einem Rückstau in der Verarbeitung kommt. Je nach Applikation kann das kritisch sein, oder auch nicht.

Wenn wir es mit einem Multicore System zu tun haben, und die Applikation alle Cores nutzt, verteilt sich die Load auf die entsprechenden Cores und “senkt” die Gesamtauslastung. Bedeutet: Ein Single-Core System mit 100% Auslastung, also einer Load von 1, wäre in einem Dual-Core System mit einer Load von 0,5 gelistet.

 

Zusammenfassend gilt:

• Load1 -> OK 
• Load über 1 -> kann OK sein, hier kommt es dann auf Erfahrungswerte des Admins an. 

 

Dein Dual-Core System mit einer dauerhaften Load von 5 kann also weiterhin sauber laufen, aber in Gesamtsicht langsamer oder träger sein. Hier kommt es dann auf die Applikation an, ob die Auswirkungen sichtbar werden oder nicht.  Eine DB, die auf einem Dual-Core System mit Load 5 läuft wird ehr als träge oder “langsam” wahrgenommen als ein http- oder Fileserver. Load ist also ein typischer Wert, der zur Interpretation viel auf den Erfahrungswerten der Admins beruht.

Generell sollte man beim Monitoring von Load-Werten auf Zeitspannen achten. Einzelne Peaks in der Load können immer auftreten und sind zu vernachlässigen – dauerhafte Loads über den Zeitraum von 5, 10 oder 15 Minuten geben deutlich mehr Hinweise ab wann vom Admin einzuschreiten ist.

Ab dem Oslevel AIX 7.2 kann es dazu kommen, dass ein Etherchannel, dem ein Device wegbricht, sich nie mehr recovern kann!

 

Hierfür gibt es einen iFix von IBM, der leider einen Haken hat…

 

klick mich oder das Bild

Leider kommt das epkg.Z File als *.tgz an, was dem ungeübten Admin eine Entpackungsorgie und ziemlich viel Frust beschehrt…

 

 

Einfach logikbefreit von *.tgz auf *.Z umbenennen und schon läuft die Sache mit

emgr -e   IV97588s2a.170714.72TL01SP02.epkg.Z

 

Backgroundinfo:

 

**************************************************************
* ERROR DESCRIPTION:
* In recent Service Packs, for etherchannel devices in
* IEEE802.3ad mode (LACP mode), if a link port goes down or is
* disconnected, after it comes back etherchannel may never be
* able to renegotiate LACP on that port again.
*
* There is a discrepancy in the protocol used between the
* server and switch that prevents the port from being
* re-aggregated.
*
* If this issue occurs, it can be resolved temporarily by
* reconfiguring LACP mode on the etherchannel adapter. This
* will allow LACP to be renegotiated on the port for now,
* though the issue could reoccur later if the fix is still not
* applied.

 

I see LUNZ devices when the AIX servers are zoned to the disk array for the first time.  Once the real LUNs are allocated from the disk array we delete those LUNZ devices and run cfgmgr/powermt config to discover the LUNs.  Some times the LUNZ’s disappear and some times they stick around.

 

Der bis jetzt beste Weg die Dinger loszuwerden ist sie über einen crontab-Eintrag immer wieder suchen und löshen zu lassen, da es Installationen gibt, die dir nach jedem Boot und auch nach jedem cfgmgr die Dinger wieder auf den Hals hetzen…

 

lsdev -Cc disk | grep -i LUNZ| awk ‘{print $1}’ | xargs -i rmdev -Rdl {}

 

Diesen Eintrag lasse ich alle 12h laufen und bekomme so ein recht sauberes System was die LUNZ Devices angeht.

 

Also denkt dran!

Parteyyyyy ;)

 

Timestamp lesen:

0614024317 –> 06=Monat 14=Tag 02=Stunde 43=Minute 17=Jahr

 

 

 

IBM hat wohl einen kleinen Bug, was die Images des Updates angeht. Nimmt man die regulären Files aus dem Netinstall Filepack, wird beim Upload auf die HMC ein fehlendens bzImage angemerkt. Das lässt sich leider nicht umgehen, weil ein Kernel nunmal notwendig ist ;) 

Die im Netinstall Update vorliegenden img2a & img3a Dateien funktionieren wohl nicht mit dem Updater der HMC.

Nimmt man allerdings die gleichen beiden img2a & img3a Files aus dem Recoveryimage unter HMC_Recovery_V8R860_1.iso/isolinux/ funktioniert der Install einwandfrei. Checksumwerte bleiben gleich, somit müssen wirklich nur die zwei Files ausgetauscht werden.

Die benötigten Pakete liegen dann auf einem per ssh erreichbaren System:

 

• img2a (aus dem Recovery Iso)
• img3a (aus dem Recovery Iso)
• base.img
• disk1.img
• hmcnetworkfiles.sum

 

Auf der HMC sollten die „Upgradedata“ gesichert werden:

Auf Platte und USB Stick:

saveupgdata -r diskusb

Nur auf Platte:

saveupgdata -r disk

Import der Upgradefiles auf die HMC mit: 

FTP

getupgfiles -h <FTP server> -u <user id> –passwd <pwd> -d <directory> 

 

SFTP

getupgfiles -r sftp –h <system>  -u <username> -d /export/update/v8860/

Nachdem die Files kopiert wurden wird das Upgrade ausgeführt: 

chhmc -c altdiskboot -s enable –mode upgrade 

Da wir mit dem oberen Command das Upgrade in die Bootpartition geschrieben haben, wird der Reboot nun einige Zeit dauern, da dann auch gleich das Update mit anläuft.

 

Reboot

 

hmcshutdown -r -t now 

 

Dauer ca 20min