Kleine und große Linux AHAs
Beiträge getaggt mit kernel
Jeder nur ein Kreuz – CPUs Prozessen zuteilen
02. Okt
Da sind sie nun – fast überall. Die SMP Systeme (Multicore Systeme). Und zu ihnen gesellen sich auch immer mehr Programme, die mehrere CPUs nutzen können … also Multithreaded sind. Und ein altbekanntes Problem.
Lang her
Wenn “damals” ein Prozess ein wenig “überschwenglich” war und durch ein Problem (z.B.) die ganze Leistung des Systems an sich gezogen hat, dann waren das so 100% und die Kiste war tot. Je nach dem.
nicht sooo lang her
Dann kamen die Multicore Systeme und unser Prozess konnte nicht mehr das ganze System lamlegen – Juhuuu. Man konnte sich also wenigstens noch anmelden und den Prozess killen.
Heute
Tja, heute sind wir wieder bei damals. Die Multicoresysteme werden von Multithreaded Prozessen an die Wand gefahren. Toll. Ein Prozess mit 400% CPU usage 
Kann man da was tun?
Aber sicher doch. So viel man sich freut, dass das ein oder andere Programm nun mehrere Cores nutzt, so wenig brauchen viele der Programme das. Oder sagen wir mal so: Die meisten kommen auch mit 3 von 4 CPUs aus. Was mache ich also wenn ich einen Prozess habe, der so manches Mal die Kiste herunterzieht? Ich weise ihm einfach nur noch 3 der 4 CPUs zu und kann somit noch mit einer meine Anmeldung vollziehen.
Unser Freund zur Umsetzung dieses gewieften Planes heißt “taskset” (man taskset).
Grundsätzlich benötigt man lediglich 2 Informationen:
- Anzahl CPUs im System
- Anzahl CPUs die man zuweisen möchte
- ProzessID (PID) (bei einem vorhanden Prozess, ansonsten kann ein Prozess auch mit taskset gestartet werden)
CPUs
Die CPUs werden mit Hilfe einer Bitmask definiert.
CPU1 -> 0x00000001 CPU2 -> 0x00000002 CPU3 -> 0x00000004 CPU4 -> 0x00000008 ...
Möchte man eine CPU zuweisen (CPU MASK), so wird einfach die 2 für die CPU2 genommen.
xCPUs
Möchte man mehrere CPUs zuweisen, so werden diese einfach addiert (HEX!). Alle 4 CPUs wären somit “f”. CPU2 und CPU3 wäre “6″ und so weiter …
Nägel mit Köpfen
Um die CPU “Affinity” eines vorhandenen Prozesses zu setzen, nutzt man folgenden Befehl:
taskset -p <CPU MASK> <PID>
Bei Programmaufruf:
taskset <CPU MASK> <CMD>
(No Ratings Yet)
Loading ...
Home NAS mit iSCSI – Format, Crypt und gut (Teil 3/3)
12. Apr
Teil I (hier) zeigte die Einrichtung des Servers inkl. iSCSI-Target.
Teil II (hier) zeigte die Einrichtung des Initiators – des Clients.
Teil III zeigt nun die restlichen Arbeiten – verschlüsseln der Platte, formatieren und den “luxuriösen” Zugriff darauf.
Verschlüsseln
Alleine um sich davor zu schützen, irgendwelche Daten aus versehen – z.B. wenn man eine alte Festplatte verkauft – an “unbefugte” weiter zu geben, sollte man seine Daten verschlüsseln. Daher habe ich die Daten auf meinem Laptop verschlüsselt und mache gleiches natürlich auch mit meinem Backup.
Unter Linux gibt es mehrere Möglichkeiten Festplatten, Partitionen oder auch nur Dateien zu verschlüsseln. Ich halte LUKS / Cryptsetup (Homepage) für eine der einfachsten Möglichkeiten.
Unter Ubuntu ist cryptsetup nicht in der Standardinstallation enthalten. Von daher muss das Paket installiert werden ->
apt-get install cryptsetup
Aus dem vorhergehenden Artikel sollten wir eine weitere Festplatte im System sehen. Beispielsweise /dev/sdb. Auf dieser Platte legen wir nun eine Partition an (/dev/sdb1) und verschlüsseln diese:
cryptsetup luksFormat /dev/sdb1
Nach Aufruf dieses Befehls wird nach einer Passphrase gefragt. Diese sollte – wie jedes Passwort – möglichst sicher gewählt werden. Mit Hilfe von LUKS / Cryptsetup werden die Daten während des Schreibens auf die Festplatte verschlüsselt, bzw. während des Lesens entschlüsselt. Dadurch dauert die Initiale Verschlüsselung nicht lange. Wirklich verschlüsselte Daten gelangen erst mit der Formatierung auf den Datenträger.
Formatieren
Die Passphrase für die Platte ist eingegeben. Nun muss die Platte ein Dateisystem bekommen damit wir damit arbeiten können. Dazu muss die Platte zuerst einmal per Luks “geöffnet” werden (wir haben bisher nur den Schlüssel angelegt).
cryptsetup luksOpen /dev/sdb1 SecureISCSI
Dieser Befehl fragt nun nach der Passphrase und legt – bei korrekter Eingabe – ein Device unter /dev/mapper mit Namen “SecureISCSI” an. Dieses ist dann das wirkliche Device, mit dem wir ganz normal arbeiten können.
mkfs.ext3 -L SecureISCSI /dev/mapper/SecureISCSI
Damit ist die Platte formatiert und kann gemountet / beschrieben werden.
Um das ganze zu vervollständigen: nach dem umounten kann das “entsicherte” Device (/dev/mapper/SecureISCSI) mit dem Befehl
cryptsetup luksClose /dev/mapper/SecureISCSI
wieder “verriegelt” werden.
Luxuriöser Zugriff
Was ich mittlerweile wirklich geil finde und vorher so gar nicht gewusst habe ist, wie man diese Festplatte nun unter Ubuntu nutzen kann.
Wenn ich meinen Laptop starte und mein Server ist verfügbar, werden mir die iSCSI Platten in Nautilus (Dateimanager) angezeigt (ich habe mehrere erzeugt). Die verschlüsselten Platten werden dabei als “290 GB verschlüsselt” angezeigt, die anderen mit ihrem Label (s. mkfs.ext3 -L …). Klickt man nun auf die “290 GB verschlüsselt”, so öffnet sich ein Dialog der mich nach der Passphrase fragt. Ich gebe die Passphrase ein und bekomme die Platte gemountet – mit ihrem Label, welches das System nun nach der Entschlüsselung erkannt hat. Ich kann direkt darauf zugreifen und beispielsweise per rsync meine Daten vom Laptop sichern.
fstab
Damit das ganze so einfach funktioniert, ist eine kleine Erweiterung der /etc/fstab notwendig. Macht man das ganze ohne diese Erweiterung, so wird man nach der Passphrase gefragt, zum mounten wird der Admin Zugriff abgefragt und als normaler User hat man dann keinen Zugriff sondern nur als root.
Um das zu umgehen trägt man in der fstab folgendes ein:
LABEL=SecureISCSI /media/SecureISCSI ext3 defaults,user,noauto 0 1
Damit ist der mountpoint bekannt und das wichtigste – es sind Optionen gesetzt. Die interessanteste dabei ist “user”, was so viel bedeutet wie “jeder Benutzer darf dieses Device auf diesem Mountpoint mounten und es auch wieder umounten”.
Wichtig ist hier auch, dass man dem Filesystem ein Label vergibt. Die iSCSI Platten müssen nicht immer den gleichen Gerätenamen (z.B. /dev/sdb) bekommen. Je nach dem ob beispielsweise ein USB Stick eingesteckt ist, kann es auch mal /dev/sd{c,d,e,f…} sein. Hat man jedoch ein Label vergeben, so spielt das eigentliche Device keine Rolle mehr. Alternativ könnte man auch mit der UUID arbeiten.
Ich hoffe dieser Artikel war recht interessant – über Feedback würde ich mich durchaus freuen
.
(No Ratings Yet) Loading ... Home NAS mit iSCSI – Initiator (Teil 2/3)
06. Apr
In Teil I (hier) hatten wir die Einrichtung des Servers inkl. iSCSI-Target gezeigt. Teil II zeigt die Einrichtung des Initiators – des Clients.
Pakete
Wir gehen von einem Ubuntu Karmic (9.10) aus. Um iSCSI nutzen zu können wird das Paket open-iscsi benötigt.
apt-get install open-iscsi
Konfiguration
Nach der Installation findet sich ein neues Verzeichnis unter /etc/ -> iscsi – dort befinden sich die Konfigurationsdateien …
initiatorname.iscsi
Dort steht quasi der Name des Initiators. Unter Debian wird bei der Installation eine ID generiert, die eindeutig ist. Möchte man den Client jedoch eindeutig zuordnen können, so sollte man den Namen in etwas “sprechendes” anpassen.
iscsid.conf
In dieser Datei werden die Defaults definiert, die von dem Daemon am Ende genutzt werden. Um mit unserer Serverseitigen Konfiguration zu arbeiten funktioniert die folgende:
node.startup = automatic node.conn[0].startup = automatic node.session.auth.authmethod = CHAP node.session.auth.username = linux-aha node.session.auth.password = secret node.session.auth.username_in = linux-aha node.session.auth.password_in = password discovery.sendtargets.auth.authmethod = CHAP discovery.sendtargets.auth.username = linux-aha discovery.sendtargets.auth.password = secret node.session.timeo.replacement_timeout = 120 node.conn[0].timeo.login_timeout = 15 node.conn[0].timeo.logout_timeout = 15 node.conn[0].timeo.noop_out_interval = 5 node.conn[0].timeo.noop_out_timeout = 5 node.session.err_timeo.abort_timeout = 15 node.session.err_timeo.lu_reset_timeout = 20 node.session.initial_login_retry_max = 8 node.session.cmds_max = 128 node.session.queue_depth = 32 node.session.iscsi.InitialR2T = Yes node.session.iscsi.ImmediateData = No node.session.iscsi.FirstBurstLength = 262144 node.session.iscsi.MaxBurstLength = 16776192 node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072 discovery.sendtargets.iscsi.MaxRecvDataSegmentLength = 32768 node.session.iscsi.FastAbort = Yes
Damit ist die Konfiguration bereits erledigt.
Discover
Um das ganze ans Rennen zu bringen muss man einen sog. Discover ausführen. Das ist vergleichbar mit einem SCSI Busscan. Da wir die Default Konfiguration für open-iscsi bereits angepasst haben, kann man den Discover Befehl auf das nötigste reduzieren:
root@machine$: iscsiadm -m discovery -t sendtargets -p <iSCSI Targethost> iqn.2008-04.local.home:SecureISCSI
So oder so ähnlich sollte der Output aussehen. Es sollte also – vergleichbar mit einem SCSI Busscan ein Device gefunden werden.
Mit dem Discover wurde nun unterhalb von /etc/iscsi/nodes die Konfiguration für dieses Device angelegt. Dadurch ist das Device dem Daemon bekannt und kann beim Systemstart gesucht und ggf. verbunden werden. Nach dem Discover genügt ein restart des Daemons um das Device im System verfügbar zu machen.
/etc/init.d/open-iscsi restart
Platte da ?
Nach dem restart sollte die neue Platte vorhanden sein. Am einfachsten hilft ein “fdisk -l” dabei, die neue Platte zu finden.
(No Ratings Yet) Loading ... Home NAS mit iSCSI – Server & iSCSI Target (Teil 1/3)
05. Apr
Zuhause in irgendeiner Art ein System zu haben um Daten zu speichern, ist mittlerweile nichts besonderes mehr. Die einen nutzen diese Speicher um der Familie gemeinsamen Zugriff zu gewähren, die anderen um Daten – beispielsweise vom Laptop – zu sichern. Wenn das NAS dann auch gespiegelte Festplatten besitzt dürfte eigentlich nicht viel passieren.
Man sollte sich wirklich einmal Gedanken darum machen was los ist, wenn man die Daten des Laptops oder des Rechners zu Hause verliert – zum Beispiel durch einen Festplattendefekt. Also mir persönlich ist das keine angenehme Vorstellung. Deshalb habe ich mir auch das System aufgebaut, welches hier beschrieben wird. Ich finde es wirklich einfach zu benutzen und es erfüllt seinen Zweck mehr als manche gekauften Lösungen.
Warum überhaupt iSCSI ?
Wenigstens unter Linux (mit anderen OSs kenne ich das nicht) hat das ganze den Charme, das man die per iSCSI an gereichte Festplatte (oder das Volume) als normale Festplatte sieht – als Blockdevice. Das ist ein Unterschied zu beispielsweise NFS oder Samba. Des Weiteren ist iSCSI, sofern man eine passende Netzwerkgeschwindigkeit hat, auch recht schnell. Um das ganze recht performant nutzen zu können sollte man also wenigstens über Gigabit Ethernet verfügen. Damit ist auch schon ein weiterer Vorteil von iSCSI angesprochen, der es gerade auch in Firmen interessant macht – man benötigt “nur” Netzwerk. Keine spezielle Verkabelung oder ähnliches. In Firmen würde man allerdings das iSCSI Geschäft über zwei (redundante) dedizierte Netzwerkinterfaces laufen lassen.
Der “Server”
Der “Server” besteht aus einem PC, der mit mindestens zwei Festplatten ausgestattet ist. Server schreibe ich in Anführungszeichen, da die Hardware natürlich keine Serverhardware ist und mein System auch nur dann läuft, wenn es gebraucht wird. Des Weiteren ist an dem PC ein USB Stick angeschlossen, der mit >4GB das Betriebssystem beherbergt. Der USB Stick deshalb, da man auf diese Weise die beiden vorhandenen Festplatten komplett für das Raid nutzen kann und nicht einen Teil für das OS verliert. Man kann es natürlich auch anders machen – ich habs halt so gemacht.
OS
Auf dem USB Stick wird das OS installiert. Dazu bootet man beispielsweise mit einer Ubuntu Live CD (ich habe den Ubuntu Server genommen) und installiert anstatt auf die Platten auf den Stick. Da wir lediglich die eingebauten Festplatten als iSCSI bereitstellen möchten, sind während der Installation keine besonderen Pakete nötig – einfach ein Minimalsystem installieren. Auf die Installation an sich gehe ich hier nicht weiter ein.
Raid
Nachdem das System installiert ist und erfolgreich von dem USB Stick bootet, kann man das Raid Device erstellen. Dazu müssen die Tools installiert werden:
apt-get install mdadm
Nach der Installation kann mit Hilfe von
mdadm --create /dev/md0 --level=1 raid-devices=2 /dev/sda1 /dev/sdb1
das Raid Device angelegt werden. In dem Beispiel würde das Device aus /dev/sda1 und /dev/sdb1 bestehen. Damit auch bei Problemen nichts falsch läuft, sollte man die Raid Konfiguration in die /etc/mdadm/mdadm.conf eintragen. Das sieht beispielsweise so aus:
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=1bc8e95a:40e106f6:7756543e:82c7b110 devices=/dev/sda1,/dev/sdb1
Bereits nach dem …create Befehl beginnt das System die Platten zu synchronisieren. Diesen Vorgang sollte man abwarten, bevor man die Platten benutzt.
iSCSI Target
Um iSCSI nutzen zu können, muss das Paket iscsitarget installiert werden.
apt-get install iscsitarget
Nach der Installation findet sich unter /etc/ eine neue Konfigurationsdatei -> ietd.conf. Diese ist für die Konfiguration des iSCSI Target (-> Server) verantwortlich. Um unseren Server einzurichten verwenden wir einfach folgende Konfiguration:
Target iqn.2008-04.local.home:SecureISCSI IncomingUser linux-aha secret OutgoingUser linux-aha password Lun 0 Path=/dev/md0,Type=fileio Alias SecureISCSI MaxConnections 1 InitialR2T Yes ImmediateData No MaxRecvDataSegmentLength 8192 MaxXmitDataSegmentLength 8192 MaxBurstLength 262144 FirstBurstLength 65536 DefaultTime2Wait 2 DefaultTime2Retain 20 MaxOutstandingR2T 8 DataPDUInOrder Yes DataSequenceInOrder Yes ErrorRecoveryLevel 0 HeaderDigest CRC32C,None DataDigest CRC32C,None Wthreads 8
Mit dieser Konfiguration ist iscsitarget fertig konfiguriert und nach einem reload des Dienstes steht die Platte zur Verfügung.
Wie man sieht gibt es unter iSCSI auch eine – naja – Authentifizierung. Das ganze als sicher zu bezeichnen würde ich mich nicht wagen, allerdings ist es besser als nichts und man kann sich damit auch ein wenig vor Fehlern schützen, in dem man verschiedene Benutzer und Passwörter vergibt.
Im nächsten Teil geht es dann um den Initiator – den Client.
(No Ratings Yet) Loading ...
CPU Flags: Was will mir der Künstler damit sagen ?
17. Mrz
Manchmal ist es interessant zu wissen, was eine CPU wirklich kann. Kann meine CPU 64bit? Kann sie Virtualisierung?
Unter Linux bekommt man die Informationen mit Hilfe von
[root@hanswurst ~]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz stepping : 10 cpu MHz : 1998.000 cache size : 6144 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx smx est tm2 cx16 xtpr lahf_lm bogomips : 5670.45
Interessant dabei ist der Eintrag “flags”. Beispielsweise bedeutet “lm” 64bit (Long Mode) – ist ja auch quasi direkt ersichtlich – “ht” -> Hyper Threading oder “vmx” ist die Virtualisierung.
Aber was bedeuten all die anderen flags ?
(sorry, das ganze Ding wollte ich nicht übersetzen)
| flag | meaning |
|---|---|
| 3DNOW | A multimedia extension created by AMD for its processors, based on / almost equivalent to Intel’s MMX extensions |
| 3DNOWEXT | 3DNOW Extended. Also known as AMD’s 3DNow!Enhanced 3DNow!Extensions |
| APIC | Advanced Programmable Interrupt Controller |
| CLFSH/CLFlush | Cache Line Flush |
| CMOV | Conditional Move/Compare Instruction |
| CMP_Legacy | Register showing the CPU is not Hyper-Threading capable |
| Constant_TSC | on Intel P-4s, the TSC runs with constant frequency independent of cpu frequency when EST is used |
| CR8Legacy | ? |
| CX8 | CMPXCHG8B Instruction. (Compare and exchange 8 bytes. Also known as F00F, which is an abbreviation of the hexadecimal encoding of an instruction that exhibits a design flaw in the majority of older Intel Pentium CPU). |
| CX16 | CMPXCHG16B Instruction. (CMPXCHG16B allows for atomic operations on 128-bit double quadword (or oword) data types. This is useful for high resolution counters that could be updated by multiple processors (or cores). Without CMPXCHG16B the only way to perform such an operation is by using a critical section.) |
| DE | Debugging Extensions |
| DS | Debug Store |
| DS_CPL | CPL qualified Debug Store (whatever CPL might mean in this context) |
| DTS | Could mean Debug Trace Store or Digital Thermal Sensor, depending on source |
| EIST/EST | Enhanced Intel SpeedsTep |
| FXSR | FXSAVE/FXRSTOR. (The FXSAVE instruction writes the current state of the x87 FPU, MMX technology, Streaming SIMD Extensions, and Streaming SIMD Extensions 2 data, control, and status registers to the destination operand. The destination is a 512-byte memory location. FXRSTOR will restore the state saves). |
| FXSR_OPT | -unknown- |
| HT | Hyper-Transport. Note that the same abbreviation might is also used to indicate Hyper Threading (see below) |
| HTT/HT | Hyper-Threading. An Intel technology that allows quasi-parallel execution of different instructions on a single core. The single core is seen by applications as if it were two (or potentially more) cores. However, two true CPU cores are almost always faster than a single core with HyperThreading. This flag indicates support in the CPU when checking the flags in /proc/cpuinfo on Linux systems. |
| HVM | Hardware support for virtual machines (Xen abbreviation for AMD SVM / Intel VMX) |
| LAHF_LM | Load Flags into AH Register, Long Mode. |
| LM | Long Mode. (64bit Extensions, AMD’s AMD64 or Intel’s EM64T). |
| MCA | Machine Check Architecture |
| MCE | Machine Check Exception |
| MMX | It is rumoured to stand for MultiMedia eXtension or Multiple Math or Matrix Math eXtension, but officially it is a meaningless acronym trademarked by Intel |
| MMXEXT | MMX Extensions – an enhanced set of instructions compared to MMX |
| MON/MONITOR | CPU Monitor |
| MSR | RDMSR and WRMSR Support |
| MTRR | Memory Type Range Register |
| NX | No eXecute, a flag that can be set on memory pages to disable execution of code in these pages |
| PAE | Physical Address Extensions. PAE is the added ability of the IA32 processor to address more than 4 GB of physical memory using Intel’s 36bit page addresses instead of the standard 32bit page addresses to access a total of 64GB of RAM. Also supported by many AMD chips |
| PAT | Page Attribute Table |
| PBE | Pending Break Encoding |
| PGE | PTE Global Bit |
| PNI | Prescott New Instruction. This was the codename for SSE3 before it was released on the Intel Prescott processor (which was later added to the Pentium 4 family name). |
| PSE | Page Size Extensions. (See PSE36) |
| PSE36 | Page Size Extensions 36. IA-32 supports two methods to access memory above 4 GB (32 bits), PSE and PAE. PSE is the older and far less used version. For more information, take a look at [1]. |
| SEP | SYSENTER and SYSEXIT |
| SS | Self-Snoop |
| SSE | Streaming SIMD Extensions. Developed by Intel for its Pentium III but also implemented by AMD processors from Athlon XP onwards |
| SSE2 | Streaming SIMD Extensions 2. (An additional 144 SIMDs.) Introduced by Intel Pentium 4, on AMD since Athlon 64 |
| SSE3 | Streaming SIMD Extensions 3. (An additional 13 instructions) introduced with “Prescott” revision Intel Pentium 4 processors. AMD introduced SSE3 with the Athlon 64 “Venice” revision |
| SSSE3 | Supplemental Streaming SIMD Extension 3. (SSSE3 contains 16 new discrete instructions over SSE3.) Introduced on Intel Core 2 Duo processors. No AMD chip supports SSSE3 yet. |
| SSE4 | Streaming SIMD Extentions 4. Future Intel SSE revision adding 50 new instructions which will debut on Intel’s upcoming “Nehalem” processor in 2008. Also known as “Nehalem New Instructions (NNI)” |
| SVM | Secure Virtual Machine. (AMD’s virtualization extensions to the 64-bit x86 architecture, equivalent to Intel’s VMX, both also known as HVM in the Xen hypervisor.) |
| TM | Thermal Monitor |
| TM2 | Thermal Monitor 2 |
| TSC | Time Stamp Counter |
| VME | Virtual-8086 Mode Enhancement |
| VMX | Intel’s equivalent to AMD’s SVM |
| XTPR | TPR register chipset update control messenger. Part of the APIC code |
(No Ratings Yet) Loading ...
Mehr Bandbreite: Bonding mit Cisco – Doppelbonding ?
01. Mrz
Wie in dem Original Artikel beschrieben, ist es nicht möglich ein Bonding dieser Art über mehrere Switches einzurichten. Dadurch hat man ein Redundanzproblem. Sollte dieser eine Switch ausfallen, so hat das System die Verbindung zum Netzwerk komplett verloren.
Die Idee war nun quasi “bond bonded Interfaces”. Also 2 bonding Interfaces zu einem weiteren zusammenfassen und dadurch beides bekommen. Das ganze würde dann also so aussehen:
Leider darf ich die Welt enttäuschen. Das funktioniert nicht. Wenigstens zur Zeit können unter Linux keine bonding Interfaces Slaves für ein weiteres bonding Interface sein. Laut RedHat: “Bonding on top of bonded interface would not work properly due to the implementation design of the kernel code”.
(No Ratings Yet) Loading ... Mehr Bandbreite: Bonding mit Cisco
25. Feb
Gründe um Server mehrfach an die Netzwerkinfrastruktur anzubinden gibt es mehrere. In den meisten Fällen wird das (unter Linux) so genannte “bonding” dazu genutzt, einen Server an mehrere Switches anzubinden um die Redundanz zu erhöhen, wobei die Durchsatzrate dabei nicht erhöht wird – es wird immer nur eine Verbindung genutzt; sollte ein Switch ausfallen ist das System trotzdem weiterhin erreichbar.
| |
|port3 port3|
+-----+----+ +-----+----+
| |port2 ISL port2| |
| switch A +--------------------------+ switch B |
| | | |
+-----+----+ +-----++---+
|port1 port1|
| +-------+ |
+-------------+ host1 +---------------+
eth0 +-------+ eth1
Quelle: http://www.cyberciti.biz/howto/question/static/linux-ethernet-bonding-driver-howto.php
Meeeehr Bandbreite
Was wir hier möchten ist mehr Bandbreite. Dazu kann man – z.B. mit einem Cisco Switch – den Linux Bonding Mechanismus dazu nutzen, beide Verbindungen an einen Switch zu bündeln und dem entsprechend die Bandbreite zu verdoppeln. Damit habe ich auch schon ein Problem dabei angesprochen. Dieser Mechanismus funktioniert nur auf einem Switch. Man kann keinen “Etherchannel” (aus Cisco Sicht) über mehrere Switches bauen. Das damit entstandene Problem ist, dass ich keine Redundanz aufbauen kann im Sinne von “siehe oben”. Fällt dieser eine Switch aus, ist auch die Netzwerkverbindung komplett weg.
+----------+ +----------+ +--------+
| |eth0 port1| +-------+ Host B |
| Host A +------------+ switch |port3 +--------+
| +------------+ | +--------+
| |eth1 port2| +------------------+ Host C |
+----------+ +----------+port4 +--------+
Quelle: http://www.cyberciti.biz/howto/question/static/linux-ethernet-bonding-driver-howto.php
Konfiguration auf der Linux Seite
Die Konfiguration auf der Linux Seite sieht an sich eine normale Bonding Konfiguaration vor; hier die kurze Version für ein bond0:
/etc/sysconfig/network-scripts/ifcfg-eth0:
DEVICE=eth0 USERCTL=no ONBOOT=yes MASTER=bond0 SLAVE=yes BOOTPROTO=none
/etc/sysconfig/network-scripts/ifcfg-eth1:
DEVICE=eth1 USERCTL=no ONBOOT=yes MASTER=bond0 SLAVE=yes BOOTPROTO=none
/etc/sysconfig/network-scripts/ifcfg-bond0:
DEVICE=bond0 IPADDR=192.168.1.1 NETMASK=255.255.255.0 NETWORK=192.168.1.0 BROADCAST=192.168.1.255 ONBOOT=yes BOOTPROTO=none USERCTL=no
Normalerweise trägt man nun in der /etc/modprobe.conf folgendes ein (eine Variante):
alias bond0 bonding options bond0 mode=1 miimon=100
Damit wird das Modul für bonding geladen und festgelegt in welchem Modus das ganze arbeitet.
- mode=1 -> bedeutet “active-backup” – eine aktive Verbindung und die andere als Backup (unbenutzt für Traffic)
- miimon=100 -> damit wird alle 100 millisekunden per MII geprüft
Wir möchten aber nicht active-backup sondern einen PortChannel nach “IEEE 802.3ad” -> Dynamic link aggregation. Laut Doku:
Creates aggregation groups that share the same speed and duplex settings. Utilizes all slaves in the active aggregator according to the 802.3ad specification.
Dabei wird also eine Gruppe aus “Links” gebildet, die dann zusammen genutzt werden. Die Konfiguration dafür auf der Linux Seite ist sehr einfach, da lediglich die Einstellung für das bonding Device in der /etc/modprobe.conf geändert werden müssen. Also:
alias bond0 bonding options bond0 mode=4 lacp_rate=1 miimon=100
- mode=4 -> IEEE 802.3ad; ein Protokollstandard, den auch Cisco verwenden kann
- lacp_rate=1 -> dieser Parameter ist optional und legt fest, wie oft die Link-Parameter zwischen Switch und Server abgeglichen werden sollen (s. Bonding Howto)
Konfiguration der Cisco Seite
Auf dem Switch wird ein neuer Port-Channel angelegt …
interface Port-channel24 description POC-to-Linux-Server switchport <switchport access vlan 152 | switchport mode trunk> switchport mode access no ip address spanning-tree portfast end
und dann die korrespondierenden Interfaces …
interface GigabitEthernet3/33 description POC-to-Linux-Server switchport <switchport access vlan 152 | switchport mode trunk> switchport mode access no ip address channel-protocol lacp channel-group 24 mode passive end
Wie in den Beispielen zu sehen, kann man den Port-Channel so einrichten, dass nur ein VLAN durchgereicht wird oder auch als Trunk. Im Trunk mode würden dann alle VLANs durchgereicht und man könnte über eine VLAN Netzwerkkonfiguration beispielsweise einen “HT Router” (High Throughput) bauen.
An sich war es das. Der Server sollte nun die doppelte Bandbreite zum Switch hin haben. Am sinnigsten ist eine solche Anbindung natürlich an den zentralen Netzwerkkomponenten (Core Switches / Backbone). Es bringt nicht viel mit 2 oder sogar 4 Gbit/s an einen Switch angebunden zu sein, der seinerseits nur mit 1Gbit/s an dem Backbone angeschlossen ist.
(No Ratings Yet) Loading ...Neuer Kernel und VMware Config
07. Mai
Sobald ein neuer Kernel auf einem VMware Gast installiert wird, muss nach dem nächsten Reboot vmware-config-tools.pl aufgerufen werden, um unter anderem die Netzwerk Kernel Module für den neuen Kernel einzurichten. Dumm nur, ohne Netzwerk muss alles über die Konsole durchgeführt werden.
Abhilfe bringt folgendes InitV Script: (/etc/init.d/vmwareautoconfig)
#!/bin/bash
# chkconfig: 2345 00 00
# description: Checks and installs automatically vmware modules for new kernel
if [ "$1" == "start" ] ; then
if [ ! -e /lib/modules/`uname -r`/.vmware_installed ]; then
/usr/bin/vmware-config-tools.pl --default >/var/log/vmware_config_last.log 2>&1
touch /lib/modules/`uname -r`/.vmware_installed
fi
fi
Auf einem Red Hat System noch mit ausführbar machen und mit chkconfig --add vmwareautoconfig in den Bootprozess einbinden und man muss sich nie wieder um vmware-config-tools.pl kümmern.
Kurz zum Skript:
Sobald ein neuer Kernel bootet, für den vmware-config-tools.pl noch nicht ausgeführt wurde (siehe Trigger Datei), führt es vmware-config-tools.pl --default aus. Im Anschluss wird die Trigger Datei /lib/modules/<kernel>/.vmware_installed erzeugt.
Soll vmware-config-tools.pl noch einmal beim nächsten Boot ausgeführt werden, einfach /lib/modules/<kernel>/.vmware_installed löschen.
Der Bootvorgang läuft dann wie gewohnt weiter und der VMware Gast hat gleich beim ersten Boot Netzwerk!
(No Ratings Yet) Loading ...
