Onderwerp: Stabiliteit en performance VPS testen

Beste WHTers,

Ik wil graag een VPS laten testen op performance en stabiliteit. Het betreft een CentOS 6.3 installatie. De VPS (KVM) draait op een Dell R310, de storage van de VPS staat op een Dell R510 (raid 10).

Ik heb zelf sterk het gevoel dat er zo af en toe een vertraging zit tussen de R310 en R510.

Iemand die de VPS eens kan stressen? Het betreft een schone installatie.

Alvast bedankt!

Sequentieel schrijven op jouw VPS :

8489271296 bytes (8.5 GB) copied, 104.08 s, 81.6 MB/s
8489271296 bytes (8.5 GB) copied, 90.4694 s, 93.8 MB/s
8489271296 bytes (8.5 GB) copied, 74.2823 s, 114 MB/s

Sequentieel lezen op jouw VPS :

8489271296 bytes (8.5 GB) copied, 83.3361 s, 102 MB/s
8489271296 bytes (8.5 GB) copied, 64.2412 s, 132 MB/s
8489271296 bytes (8.5 GB) copied, 77.9571 s, 109 MB/s

Verbinding tussen server en storage gaat waarschijnlijk
over gigabit ethernet, daar lijkt het in ieder geval wel op.

Klopt inderdaad. Was de storage continu beschikbaar? Ik heb vaak het gevoel dat er een timeout van een aantal seconden plaatsvind.

Niets speciaals gemerkt nee, heb de logs
gecheckt en daar valt niets te bespeuren.
Op welke manier connecteer je op de VPS
als je dit waarneemt ?

Ik heb een aantal vpsjes lopen op die node, waaronder een mailserver, webserver en sql server. Doen allemaal niet bijzonder veel verkeer. Maar vaak/soms tijdens het ophalen van mail, bezoeken van een site, of gewoon via de ssh console merk ik een timeout.

Ik kan dan typen wat ik wil in de console, maar dan gebeurt en helemaal niets, en een paar seconden later verschijnen de tekens wel in beeld. Bij dedicated servers heb ik geen problemen.

Is het storage verkeer en het lijntje naar buiten wel goed gescheiden? Kloppen de netmasks? Gebruik je bonding?

Ik heb de R310 direct verbonden met de R510, daar zou het probleem dus niet mogen zitten.

Op de R510 gebruik ik de volgende settings (Open-e):
Bonding mode: balance-tlb
Address IP 10.0.5.10
Netmask 255.255.255.0
Broadcast 10.0.5.255
Gateway 10.0.5.1

Op de R310 gebruik ik de volgende settings (Centos 6.3):

ifcfg-bond0
DEVICE=bond0
ONBOOT=yes
IPADDR=10.0.5.11
NETMASK=255.255.255.0
NETWORK=10.0.5.0
USERCTL=no
BOOTPROTO=no
MTU=9216

ifcfg-p1p1
DEVICE="p1p1"
ONBOOT=yes
USERCTL=no
MASTER=bond0
SLAVE=yes
BOOTPROTO=no
MTU=9216

ifcfg-p1p2
DEVICE="p1p2"
ONBOOT=yes
USERCTL=no
MASTER=bond0
SLAVE=yes
BOOTPROTO=no
MTU=9216

Oorspronkelijk geplaatst door CeeReM.com

..Maar vaak/soms tijdens het ophalen van mail, bezoeken van een site, of gewoon via de ssh console merk ik een timeout.

Ik kan dan typen wat ik wil in de console, maar dan gebeurt en helemaal niets, en een paar seconden later verschijnen de tekens wel in beeld.

Umm.. waarom denk je dat dit syndroom komt door je storage? Een ssh sessie draait normaalgesproken volledig in memory. Als die stopt met reageren, dan is dat niet omdat je storage er even uitligt, de reden daarvoor zal je toch echt elders moeten zoeken.

Het heeft eerder iets te maken met bijvoorbeeld:
- swapping - is de host druk bezig als hij tijdelijk even stopt?
- netwerk configuratie problemen - werkt je DNS betrouwbaar? is er een route probleem? een failover probleem?
- vm configuratie problemen - is er iets te zien in de logs van je virtuele machines ten tijde van de pauzes?
- ... iets compleet anders... echt tijd om je logs zeer goed te gaan bestuderen.
Is dit de enige host met VPSjes die je draait? Zo niet, wat gebeurd er als je een van de "haper" VPSsen naar een andere host verplaatst?

Oorspronkelijk geplaatst door wila

Umm.. waarom denk je dat dit syndroom komt door je storage? Een ssh sessie draait normaalgesproken volledig in memory. Als die stopt met reageren, dan is dat niet omdat je storage er even uitligt, de reden daarvoor zal je toch echt elders moeten zoeken.

Het heeft eerder iets te maken met bijvoorbeeld:
- swapping - is de host druk bezig als hij tijdelijk even stopt?
- netwerk configuratie problemen - werkt je DNS betrouwbaar? is er een route probleem? een failover probleem?
- vm configuratie problemen - is er iets te zien in de logs van je virtuele machines ten tijde van de pauzes?
- ... iets compleet anders... echt tijd om je logs zeer goed te gaan bestuderen.
Is dit de enige host met VPSjes die je draait? Zo niet, wat gebeurd er als je een van de "haper" VPSsen naar een andere host verplaatst?

Bedankt voor je reactie. Ik ga een aantal punten uitzoeken.

Overigens merk ik wel vaak op, dat als ik een bestand probeer te openen dat dat nét het moment is dat alles blijft hangen. Nu ga ik twijfelen of ik dit ook gewoon in de console heb. Meestal als ik een bestand aan het bewerken ben etc. Dus wel echt bij een actie.

- swapping - is de host druk bezig als hij tijdelijk even stopt?
Nee, veel geheugen beschikbaar, geen swap, lage CPU

- netwerk configuratie problemen - werkt je DNS betrouwbaar? is er een route probleem? een failover probleem?
Ik maak gebruik van de Google DNS. Op wat voor manieren kan ik controleren of er route problemen zijn?

- vm configuratie problemen - is er iets te zien in de logs van je virtuele machines ten tijde van de pauzes?
Welke logs kan ik het beste kijken?

- ... iets compleet anders... echt tijd om je logs zeer goed te gaan bestuderen.
Welke logs raad jij aan om in te kijken?

- Is dit de enige host met VPSjes die je draait? Zo niet, wat gebeurd er als je een van de "haper" VPSsen naar een andere host verplaatst?
Momenteel is deze host de enigste die in verbinding staat met de 'SAN', zonder tussenkomst van een switch.

Oorspronkelijk geplaatst door CeeReM.com

Overigens merk ik wel vaak op, dat als ik een bestand probeer te openen dat dat nét het moment is dat alles blijft hangen. Nu ga ik twijfelen of ik dit ook gewoon in de console heb. Meestal als ik een bestand aan het bewerken ben etc. Dus wel echt bij een actie.

Daarom vroeg ik ook, waarom denk je dat?
Zelf zou ik in dit geval denkelijk meerdere ssh sessies openen met een probleem VM top draaiend in de andere sessie om te kijken wat de processen. Andere vragen die ik zou proberen te beantwoorden zouden zijn:
- als het probleem gebeurd is dit dan 1 VM, of alle VMs die aan die storage hangen?
- is de host zelf gewoon responsive ten tijde van een hang?

Oorspronkelijk geplaatst door CeeReM.com

Ik maak gebruik van de Google DNS. Op wat voor manieren kan ik controleren of er route problemen zijn?

een "nslookup google.com" werkt gewoon zoals je verwacht? Gaat ook via de google server?
Dat laatste vraag ik omdat je zegt dat je centOS6.3 gebruikt en misschien dat netwerk manager iets anders doet dan je verwacht. Al ga ik er eigenlijk een beetje vanuit dat je NM hebt uitgezet voor een server.

Sorry over mijn "route" opmerking, ik denk niet dat het relevant is in dit geval. Maar je kan het "route" commando gebruiken om de route tabel te bekijken.

Oorspronkelijk geplaatst door CeeReM.com

- vm configuratie problemen - is er iets te zien in de logs van je virtuele machines ten tijde van de pauzes?
Welke logs kan ik het beste kijken?

- ... iets compleet anders... echt tijd om je logs zeer goed te gaan bestuderen.
Welke logs raad jij aan om in te kijken?

Wel bekijk om te beginnen de /var/log/messages log op je VPS en op je host rond de tijd dat het systeem hangt. Het is dus belangrijk dat de datum/tijd van je machines overeenkomt met die vanaf waar je inlogt.

edit: Ik gebruik zelf geen KVM, maar bij vmware heb je per VM een log van wat de VM aan het doen is, cq welke problemen er optreden. Bij storage problemen zie je het daar -iig voor VMware- zeker terug. Eigenlijk verwacht ik dat KVM iets vergelijkbaars heeft.

Ik heb een tracetrout op de host zelf uitgevoerd. Volgens mij gaat hier iets fout:



traceroute -n -w 2 -q 2 -m 30 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 * *
2 188.122.95.81 0.313 ms *
3 188.122.95.65 2.215 ms 2.328 ms
4 195.69.144.247 2.307 ms *
5 209.85.248.118 2.147 ms *
6 * *
7 * *
8 * *
9 8.8.8.8 5.868 ms 6.156 ms



Maar soms werkt het wel:
traceroute -n -w 2 -q 2 -m 30 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 213.****** (gateway IP) 0.173 ms 0.148 ms
2 188.122.95.89 0.143 ms 188.122.95.81 0.264 ms
3 * 109.200.218.85 2.005 ms
4 * *
5 * *
6 * *
7 * *
8 * *
9 8.8.8.8 5.877 ms 5.943 ms

Oei, nu in '/var/log/messages' ook het volgende:

Mar 15 08:52:15 node1 kernel: connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 16086111801, last ping 16086116801, now 16086121801
Mar 15 08:52:15 node1 kernel: connection3:0: detected conn error (1011)
Mar 15 08:52:16 node1 iscsid: Kernel reported iSCSI connection 3:0 error (1011 - ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Mar 15 08:52:16 node1 kernel: connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 16086112840, last ping 16086117840, now 16086122840
Mar 15 08:52:16 node1 kernel: connection1:0: detected conn error (1011)
Mar 15 08:52:17 node1 iscsid: Kernel reported iSCSI connection 1:0 error (1011 - ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Mar 15 08:52:17 node1 kernel: connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 16086114191, last ping 16086119191, now 16086124191
Mar 15 08:52:17 node1 kernel: connection2:0: detected conn error (1011)
Mar 15 08:52:19 node1 iscsid: Kernel reported iSCSI connection 2:0 error (1011 - ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Mar 15 08:52:20 node1 iscsid: connection3:0 is operational after recovery (1 attempts)
Mar 15 08:52:21 node1 iscsid: connection1:0 is operational after recovery (1 attempts)
Mar 15 08:52:22 node1 iscsid: connection2:0 is operational after recovery (1 attempts)


en


Mar 15 09:00:37 node1 kernel: connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 16086613872, last ping 16086618872, now 16086623872
Mar 15 09:00:37 node1 kernel: connection1:0: detected conn error (1011)
Mar 15 09:00:37 node1 kernel: connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 16086614089, last ping 16086619089, now 16086624089
Mar 15 09:00:37 node1 kernel: connection2:0: detected conn error (1011)
Mar 15 09:00:39 node1 iscsid: Kernel reported iSCSI connection 1:0 error (1011 - ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Mar 15 09:00:39 node1 iscsid: Kernel reported iSCSI connection 2:0 error (1011 - ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Mar 15 09:00:52 node1 kernel: connection3:0: detected conn error (1019)
Mar 15 09:00:53 node1 iscsid: Kernel reported iSCSI connection 3:0 error (1019 - ISCSI_ERR_XMIT_FAILED: Transmission of iSCSI packet failed) state (1)
Mar 15 09:00:54 node1 iscsid: connection2:0 is operational after recovery (1 attempts)
Mar 15 09:00:54 node1 iscsid: connection1:0 is operational after recovery (1 attempts)
Mar 15 09:00:56 node1 iscsid: connection3:0 is operational after recovery (2 attempts)




Op datzelfde moment heb ik een ping lopen naar de storage server, die loopt wel continu door.

Heb je al eens in de log van je switch gekeken? Misschien dat daar iets in is te zien. Het zou bijvoorbeeld kunnen zijn dat je switch niet helemaal blij wordt van de ingestelde bond. Dan kun je ook wel eens van dit soort gekke dingen krijgen.

Nogmaals, ik heb geen switch tussen de twee machines staan. Ik heb ze direct met elkaar verbonden

Excuus, ik had ongeveer het gehele topic doorgelezen, maar dat heb ik net gemist blijkbaar. Dan zou je eigenlijk moeten kijken of de storageserver iets logt over de links op de NIC's of de bond zelf. Of staat daar niks over in de logs?

Ik vind het wel raar dat je packetloss hebt over je link naar internet toe en ook over de links naar je storage toe. Beetje domme vraag wellicht, maar heb je niet toevallig de bond over de verkeerde NIC's ingesteld?