Oktober 5

Open-E iSCSI VMWare vSphere recommended settings

Für VMware gibt es folgende empfohlene iSCSI Einstellungen:

maxRecvDataSegmentLen=262144
MaxBurstLength= 1048576
Maxxmitdatasegment=262144
FirstBurstLength=65536
DataDigest=None
maxoutstandingr2t=8
InitialR2T=No
ImmediateData=Yes
headerDigest=None
Wthreads=8


Laut Open-E Support wird das auch so ab DSS V7up56 so eingestellt. Ältere Systeme sollten von Hand angepasst werden, generell ist hier eine Kontrolle nach der Installation sicher kein Fehler.

Die iSCSI Tuning Optionen findet man in der Console mit CTRL+ALT+W –> 0. Tuning Options –> 4. iSCSI daemon options –> 1. Target options

open-e_iscsi1

Der iSCSI Cluster muss für diese Änderung deaktiviert sein.

 

Was effektiv von VMware beim Verbinden der iSCSI Laufwerke ausgehandelt wird, kann im kernel-sys.log nachvollzogen werden (WebGUI –> Status –> Hardware –> Logs).

Januar 21

Open-E: A success story from the mechanical engineering industry

Ein Jahr später fand "meine" Success Story auch den Weg in das englische Open-E Blog.

OPTIMA is a German leader in manufacturing filling and packaging machines, owning a large redundant data center in one of their headquarters in  Schwäbisch Hall. Their main constraint was to centralize all services so that the administration could work directly from the headquarter.

That’s why they set up a centralized system based on Open-E DSS V7 and VMware ESX Server. With the help of Open-E, OPTIMA was able to achieve stability and a redundant system with no single point of failure. Additionally, Open-E DSS V7 provided the scalability and availability they needed, being at the same time hardware-independent.

Manuel Kuss, System Administrator with OPTIMA

“Apart from its flexibility, it was the stability of the Open-E systems that convinced me. We benefit from the hardware redundancy in lieu of not having any technical contact onsite in remote locations. The system keeps running even if hardware components fail, and can easily be rebooted even after power outages. By using commodity servers, we do not face any problems regarding hardware supplies and do not need to use any specific SAN disk drives.”

Read full case study

September 29

iSCSI mit Open-E DSS – IP Madness

Mit dem Wechsel auf Open-E DSS V7 habe ich mir nun eine neue Vorgehensweise für die IP Addressen überlegt. Generell verwende ich für iSCSI das komplette 172.16.0.0/16 Netzwerk und tobe mich im kompletten Adressraum aus.

Los geht es mit den Interface IP’s der DSS Nodes.
Hier verwende ich das Schema 172.16.[eth+10].[node]
node1 – eth0 = 172.16.11.1 /24 ; node2 – eht0 = 172.16.11.2 /24
node1 – eth4 = 172.16.14.1 /24 ; node2 – eth4 = 172.16.14.2 /24

Für den iSCSI Failover lege ich dann auf jede NIC welche für MPIO ist eine virtuelle IP nach dem Schema 172.16.[(eth+10)*100].[target+100] also
iSCSI target0 – eth0 = 172.16.100.100 /24
iSCSI target1 – eth4 = 172.16.140.101 /24

Am iSCSI Target selbst verbiete ich den Zugriff über 0.0.0.0/0 und erlaube das iSCSI Netz 172.16.0.0/16.

 

Auf dem  ESX gibt es dann pro MPIO Verbindung ein eigenes Netzwerk mit jeweils einer NIC und einem VMkernel in diesem Netz nach dem Schema 172.16.[virtualip].[node]
ESX Host 1 – DSS NIC eth0 = 172.16.100.1
ESX Host 2 – DSS NIC eth4 = 172.16.140.1

 

Verwirrt? Ich auch… Deswegen noch ein paar Screenshots. :-)

Für die Storage Replikation verwende ich einen balance-rr bond mit einer ausreichenden Anzahl an NICs. Im ESX konfiguriere ich das MPIO mit Round Robin.

 Die IP des bond ist natürlich auch im 172.16.0.0 Netzwerk… Die Grafik ist hier falsch.