[Ubuntu 10.04 server] Webserver soms onbereikbaar

[Snors]

Allen,

Ik heb een VMWare Vsphere ESXi 4 testserver met daarop 2 virtuale machines geconfigureerd:
- Ubuntu 10.04 LTS x64 Webserver
- Windows Server 2008 Enterprise x64 Appserver

Er wordt op dit moment alleen met de webserver gewerkt en hier staan alleen wat php testfiles op. Wat ik merk is dat soms mijn webserver onbereikbaar is. En met onbereikbaar bedoel ik dat ik de melding in firefox krijg:
De verbinding werd geherinitialiseerd
Pagina kon niet worden geladen

Server specs zijn:
HP DL120 G7
14GB Geheugen(Webserver 6GB/Apserver 8GB)
2* 7200RPM 2TB schijven RAID 1

Wat heb ik zelf al gedaan:
- Log files apache/server zelf nagekeken. Als de timeouts optreden wordt er geen script oid. uitgevoerd. Volkomen random dus.
- Resourche allocation gechecked. Ik dacht eerst dat het aan de I/O van de disks kon liggen. Echter zie ik hier vlak voor of na de timeout geen pieken of dalen in. Zelfde geld voor CPU en Memory

Het is niet de eerste keer dat ik zoiets opzet. Begin toch sterk aan mezelf te twijfelen of ik iets vergeten ben te configureren. Wie o wie kan mij helpen?

[DAzN]

Hoe benader je je website? Is dat op ip, hostname of domainname?

Ervan uitgaande dat je apache-configuratie correct is (het werkt immers soms wel) denk ik aan een dns-issue. Het kan geen kwaad om de error en access-logs van Apache te verifiëren op de momenten dat het wel werkt.

[Snors]

DAzN schreef op dinsdag 22 mei 2012 @ 10:25:
Hoe benader je je website? Is dat op ip, hostname of domainname?

Ervan uitgaande dat je apache-configuratie correct is (het werkt immers soms wel) denk ik aan een dns-issue. Het kan geen kwaad om de error en access-logs van Apache te verifiëren op de momenten dat het wel werkt.

Per IP .. Ik zal de logs nog eens doorlopen en evt. hier posten! Thanks.

[DAzN]

Dan lijkt me dat die app server toch niet zo "inactief" is als je denkt. Schakel dat ding eens uit of zorg dat die een volledig ander ip-adres krijgt.

[Snors]

DAzN schreef op dinsdag 22 mei 2012 @ 10:36:
Dan lijkt me dat die app server toch niet zo "inactief" is als je denkt. Schakel dat ding eens uit of zorg dat die een volledig ander ip-adres krijgt.

Hmm, kreeg ook op een zeker moment random kernel panics. Heb besloten om de webserver opnieuw te installeren en het lijkt nu goed te werken. Thanks!

[Snors]

Niets lijkt minder waar... Ik heb de server opnieuw geïnstalleerd en het probleem treed nog steeds op. Nogmaals een korte beschrijving:

De timeouts treden alleen bij de Ubuntu Webserver op. De Windows Appserver blijft bereikbaar en de VMware ESX server blijft ook extern bereikbaar. Ik kan dus wel gewoon inloggen op de VMware ESX server en via de console bij de server komen. Vervolgens kan ik ook vanaf de server zelf succesvol naar buiten pingen maar inkomend verkeer blijft geblokkeerd.

Kort beschreven:
Tijdens de timeout kan ik wel:
- Windows Appserver pingen / benaderen
- ESX server benaderen
- Via de ESX console op de ubuntu webserver inloggen en naar bijvoorbeeld google.nl pingen

Na ongeveer 1 á 2 minuten wordt de webserver weer bereikbaar. Zoals ik al eerder heb gezegd heb ik vrijwel alle logfiles door gekeken maar wellicht dat ik er een over het hoofd heeft gezien. Heeft iemand enig idee in welke logfiles ik een foutmelding kan tegenkomen? Zodat ik in ieder geval gericht verder kan zoeken naar een oplossing.

Alvast bedankt!

[GlowMouse]

Zonder verhaaltje met termen als SYN of trace, valt hier weinig over te zeggen.

[ik222]

Als pings naar buiten wel werken is er dus ook inkomend verkeer mogelijk (anders zou het antwoord ook niet aankomen) maar kunnen er blijkbaar geen nieuwe sessies worden opgezet van buitenaf. Ik zou eens beginnen met te kijken wat je ziet met bijvoorbeeld tcpdump op je ubuntu bak. Zo kun je in elk geval zien of er daar iets aankomt vanaf de buitenkant. Als dat niet het geval is zul je waarschijnlijk het probleem in ESXi moeten zoeken.

Zit je Windows Appserver op dezelfde vswitch? Of nog beter, hoe zit je ESXi netwerkconfiguratie er uberhaupt uit?

[Snors]

ik222 schreef op zondag 10 juni 2012 @ 22:05:
Als pings naar buiten wel werken is er dus ook inkomend verkeer mogelijk (anders zou het antwoord ook niet aankomen) maar kunnen er blijkbaar geen nieuwe sessies worden opgezet van buitenaf. Ik zou eens beginnen met te kijken wat je ziet met bijvoorbeeld tcpdump op je ubuntu bak. Zo kun je in elk geval zien of er daar iets aankomt vanaf de buitenkant. Als dat niet het geval is zul je waarschijnlijk het probleem in ESXi moeten zoeken.

Zit je Windows Appserver op dezelfde vswitch? Of nog beter, hoe zit je ESXi netwerkconfiguratie er uberhaupt uit?

Zie hieronder mijn netwerk indeling.
vSwitch0 zit de VMkernel op, de Linux webserver en de Windows Appserver. De appserver zit een geconfigureerde firewall op zodat deze alleen Windows Updates mag instelleren en inkomende connecties vanaf de Linux webserver toelaat.

vSwitch1 hier draait de onderlinge communicatie op tussen de Windows appserver en Linux webserver. IP's zitten in een totaal verschillende reeks dan vSwitch0


Ik zal ook een uitgebreide traceroute met het aantal hops weergeven. Dit is echter wel wat moeilijk te realiseren omdat er slechts 2 tot 3 timeouts per 24 uur zijn en deze volkomen random plaatsvinden.

[Snors]

Ik ben op dit moment een logfile met tcpdump aan het maken.
Hieronder mijn interface configuratie op mijn ubuntu webserver:

eth0 Link encap:Ethernet HWaddr 00:0c:29:bc:2b:b6
inet addr:85.17.105.196 Bcast:85.17.105.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:febc:2bb6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:624977 errors:0 dropped:0 overruns:0 frame:0
TX packets:320580 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:175681298 (175.6 MB) TX bytes:71014550 (71.0 MB)

eth1 Link encap:Ethernet HWaddr 00:0c:29:bc:2b:c0
inet addr:10.0.1.20 Bcast:10.0.1.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:febc:2bc0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1265 errors:0 dropped:0 overruns:0 frame:0
TX packets:207 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:145314 (145.3 KB) TX bytes:8910 (8.9 KB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:34168 errors:0 dropped:0 overruns:0 frame:0
TX packets:34168 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3179736 (3.1 MB) TX bytes:3179736 (3.1 MB)

Vreemde is dat ik hier geen drops in de RX en TX packets zie...

[Hero of Time]

Zijn de VMWare tools aanwezig op de server?

[Snors]

Hero Of Time schreef op donderdag 14 juni 2012 @ 09:27:
Zijn de VMWare tools aanwezig op de server?

De VMWare tools zijn geïnstalleerd en de laatste versie. Ik durf ook met zekerheid te zeggen dat het alleen de ubuntu webserver is die lastig functioneert. Het lijkt wel alsof die de complete interface voor inkomend verkeer tijdelijk blokkeert of volloopt terwijl het verkeer dat er in/uit gaat minimaal is.

Ik hoop dat de tcpdump wat uitkomst geeft en wellicht dat iemand hier het licht tot een oplossing ziet.

[CAPSLOCK2000]

Wat voor een soort virtuele NIC gebruik je? Wissel eens.

[Snors]

CAPSLOCK2000 schreef op donderdag 14 juni 2012 @ 20:54:
Wat voor een soort virtuele NIC gebruik je? Wissel eens.

Ik heb zowel de virtuele NIC als physical NIC gewisseld / opnieuw toegevoegd. Nog steeds hetzelfde, ik ben echt het spoor bijster....

Is er iemand die mij tegen een gepaste vergoeding wilt helpen door een kijkje te nemen op mijn server? Dit probleem vreet echt aan me en wil het snel opgelost hebben.

[magistus]

Check iig je MAC-adressen van alle netwerkkaarten dubbel of stel eens expliciet een andere waarde hier voor in. VMWare begint volgens mij met een standaard waarde en dit geeft, bijvoorbeeld bij 2 ESX-clusters, wel eens freaky problemen.

[Snors]

magistus schreef op donderdag 21 juni 2012 @ 12:55:
Check iig je MAC-adressen van alle netwerkkaarten dubbel of stel eens expliciet een andere waarde hier voor in. VMWare begint volgens mij met een standaard waarde en dit geeft, bijvoorbeeld bij 2 ESX-clusters, wel eens freaky problemen.

Thanks voor de tip dit ga ik als ik thuis ben zeker doen. Het aanbod van hierboven blijft vooralsnog staan.. Ik ben bereid een gepaste vergoeding te betalen voor degene die mij 1-op-1 hierbij wil assisteren door remote in te loggen.

[GlowMouse]

Ik mis de resultaten van de tcpdump die je gemaakt hebt, en ook hoe makkelijk het probleem te triggeren is.

[Snors]

GlowMouse schreef op donderdag 21 juni 2012 @ 13:39:
Ik mis de resultaten van de tcpdump die je gemaakt hebt, en ook hoe makkelijk het probleem te triggeren is.

Ongeveer 1 minuut een tcpdump gemaakt tijdens een timeout. Het gaat om de eth0 interface die als volgt in geconfigureerd:
# The primary network interface
auto eth0
iface eth0 inet static
address 85.17.105.196
netmask 255.255.255.0
network 85.17.105.0
broadcast 85.17.105.255
gateway 85.17.105.254
Verder kan ik dus tijdens de timeout op de linux server wel op de ESX server zelf inloggen en via de Console interface de server bereiken. Ik heb geprobeerd om tweakers.net te pingen vanuit de Console interface tijdens een timeout en dit gaat dus wel gewoon goed(uitgaand is OK inkomend wordt geblokkeerd).

TCPDUMP:
http://g2f.nl/045v9d9

SCREENSHOT:


Het aanbod staat nog steeds om iemand die denkt dit probleem op te kunnen lossen toegang te verlenen tot de server tegen een passende vergoeding.

[GlowMouse]

In die tcpdump zie ik inkomende pings van x.83.38.48. Er wordt alleen geen reply gestuurd, waarschijnlijk doordat een firewall actief is. Inkomend verkeer wordt dus niet geblokkeerd. Mochten pings op een ander moment werken, dan heb je denk ik meerdere interfaces.

Die uitgaande ping naar tweakers.net zie ik niet terug in de tcpdump. Dit versterkt mijn vermoeden dat je meerdere interfaces hebt, en uitgaand verkeer via de verkeerde interface geroute wordt.

[ Voor 25% gewijzigd door GlowMouse op 02-07-2012 00:44 ]

[Snors]

GlowMouse schreef op maandag 02 juli 2012 @ 00:42:
In die tcpdump zie ik inkomende pings van x.83.38.48. Er wordt alleen geen reply gestuurd, waarschijnlijk doordat een firewall actief is. Inkomend verkeer wordt dus niet geblokkeerd. Mochten pings op een ander moment werken, dan heb je denk ik meerdere interfaces.

Die uitgaande ping naar tweakers.net zie ik niet terug in de tcpdump. Dit versterkt mijn vermoeden dat je meerdere interfaces hebt, en uitgaand verkeer via de verkeerde interface geroute wordt.

Ik zag dit zelf ook al inderdaad, de uitgaande pings naar tweakers.net had ik niet meegenomen in de TCPdump. Ik ga vanavond eens door de iptables heen lopen en kijken of ik daar iets kan vinden. Zal de configuratie wederom hier posten.

Zoals je zegt heb ik inderdaad 2 interfaces waarvan je de ESX configuratie hierboven kan zien. VM Network 1 is een private netwerk in de 10.0.1.x range(eth1 in linux). VM Network is het publieke netwerk naar de buitenwereld met mijn publieke IP range(eth0 in linux). Kan het zo zijn dat apache hiermee in de war raakt of zelfs mijn gehele linux server en in een keer begint te luisteren op eth1 i.p.v. eth0? Dit zou jou verhaal hierboven bevestigen ik heb alleen geen idee waar je zoiets kan instellen dat je gehele linux server standaard alles op eth0 doorstuurt tenzij anders aangegeven(in bijvoorbeeld een php script).

Toevoeging:
Zoals ik al zei ga ik kijken naar mijn iptables(een andere firewall heb ik niet geïnstalleerd). Kan het ook zo zijn dat ik dingen in ubuntu apparmor over het hoofd heb gezien? Het probleem treed niet alleen bij apache2 op maar bij de gehele server vandaar dat ik vermoed dat het eerder een firewall issue is dan een application armor issue kan iemand dit bevestigen?

[ Voor 11% gewijzigd door Snors op 02-07-2012 09:59 ]

[pennywiser]

Standaard luistert Apache op alle interfaces toch?

Lees dit eens door:

http://www.cyberciti.biz/...e-default-port-ipbinding/

Zet de firewall uit, dan weet je of het daaraan ligt.

Installeer anders Shorewall:

code:

shorewall stop
shorewall clear

[ Voor 35% gewijzigd door pennywiser op 02-07-2012 10:14 ]

[GlowMouse]

Post de output van "route -n", van "arp -n" en van "traceroute tweakers.net" eens wanneer het wel werkt, en wanneer je server onbereikbaar is.

[ Voor 5% gewijzigd door GlowMouse op 02-07-2012 10:27 ]

[Snors]

pennywiser schreef op maandag 02 juli 2012 @ 10:11:
Standaard luistert Apache op alle interfaces toch?

Lees dit eens door:

http://www.cyberciti.biz/...e-default-port-ipbinding/

Zet de firewall uit, dan weet je of het daaraan ligt.

Installeer anders Shorewall:

code:

shorewall stop
shorewall clear

Ja klopt als ik vanaf mijn Windows Appserver de 10.0.1.20 benader via de browser opent apache ook gewoon. Denk toch een firewall issue of dat linux vanwege wat voor rede dan ook in een keer alleen nog maar alles naar eth1 stuurt al lijkt me dit sterk. We zullen zien, ik ga de traceroutes / route -n proberen. Kan enige tijd duren voordat er weer een timeout optreed maar we zullen zien :)!

Thanks voor alle input in ieder geval, ik laat zo snel mogelijk wat van mij horen!

[Snors]

GlowMouse schreef op maandag 02 juli 2012 @ 10:26:
Post de output van "route -n", van "arp -n" en van "traceroute tweakers.net" eens wanneer het wel werkt, en wanneer je server onbereikbaar is.

Zojuist weer een timeout gehad. Direct na een reboot dus niet een random timeout(nadat ik de server opnieuw had gereboot werkte het weer). Resultaten:

SERVER DOWN
arp

route


SERVER UP
arp

route

traceroute


De traceroute als de server down is houden jullie tegoed bij de volgende timeout excuses hiervoor.

[Hero of Time]

Je hebt een dubbele default gateway. Dat gaat niet goed. Op je eth1, je interne LAN, heb je geen gateway nodig, tenzij die naar andere netwerk segmenten gaan. En dan is het beter om het netwerk segment als route aan te geven met een gateway, ipv alles er overheen te laten sturen.

Bijvoorbeeld, als je 192.168.0.x bereikt via 10.0.1.1, dan moet je dat op die manier aangeven, als een static route.

Als je ook kijkt tussen je down en up, zie je dat bij down 10.0.1.1 boven je werkelijke gateway staat, en bij up andersom.

[Snors]

Hero Of Time schreef op dinsdag 03 juli 2012 @ 01:00:
Je hebt een dubbele default gateway. Dat gaat niet goed. Op je eth1, je interne LAN, heb je geen gateway nodig, tenzij die naar andere netwerk segmenten gaan. En dan is het beter om het netwerk segment als route aan te geven met een gateway, ipv alles er overheen te laten sturen.

Bijvoorbeeld, als je 192.168.0.x bereikt via 10.0.1.1, dan moet je dat op die manier aangeven, als een static route.

Als je ook kijkt tussen je down en up, zie je dat bij down 10.0.1.1 boven je werkelijke gateway staat, en bij up andersom.

Dus simpel gezegd, geen gateway voor eth1 definiëren @ /etc/networking/interfaces en het is fixed??

[Hero of Time]

Ja. Waar zou je die voor nodig hebben? Er hangt geen ander netwerk achter, dus is die ook niet nodig.

[Snors]

Hero Of Time schreef op dinsdag 03 juli 2012 @ 09:17:
Ja. Waar zou je die voor nodig hebben? Er hangt geen ander netwerk achter, dus is die ook niet nodig.

True, soms denk ik gewoon te moeilijk en haal ik dit soort fratsen uit. Ik laat het topic nog open heb het gisteravond aangepast. Nog geen timeouts gehad laten we hopen dat dit het probleem heeft opgelost!