Beheer aandachtspunten

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

John Joghems

John Joghems

11/11/2017 13:16:38
Quote Anchor link
Zoals uit een andere posting blijkt had ik deze week een storing met een server.
Dus wordt het tijd om serverbeheer weer eens aandacht te geven.
Deze site gaat primair over PHP maar ik hoop dat er ruimte is voor LAMP-server beheer.

Over mijn site:
- ik huur een VPS bij een ISP
met daarbij een DA(DirectAdmin) licentie.
Met DA wordt mijn beheer simpeler door de GUI
en ik had een email-server, firewall en backup manager nodig wat in DA zit.
- heb daar zelf mbv yum een CentOS6.8-template op geinstalleerd als 'L'
- DirectAdmin heeft daar 'AMP' op geinstalleerd
zodat ik nu een LAMP-server met DirectAdmin heb.
Mijn linux kennis is helaas gering.
Op die LAMP-configuratie heb ik een -gekocht- PHP-script geinstalleerd.
Ja, op mijn VPS draait -momenteel- slechts 1 site.

A) Support hiaat
Deze week heb ik ontdekt dat ik een support-hiaat heb::
- mijn VPS wordt gesupport door de ISP
- mijn PHP-script wordt gesupport door de leverancier/sw-developer
- maar voor de middle-ware ('LAMP') heb ik eigenlijk geen support
Iemand een suggestie voor een partij waar ik zoiets zou kunnen onderbrengen ?

B) Beheer aanpak
En ja in mijn 'storing-thread' heb ik al gemerkt dat je beheer op verschillende manieren kunt doen
Je kunt het vanaf de commandline doen
Ik doe dat nu dus met DA.
Er zijn natuurlijk alternatieve ControlePanels zoals Plesk of cPanel
maar denk dat dat weinig voordeel geeft.

C) Software beheer tools
Ik heb dus sw geinstalleerd mbv yum
en iemand heeft ook al Custombuild2 geroepen
maar hier zit dus een kennishiaat bij mij.
- Als je een Controlpanel als DA gebruikt is dan iets als yum of Custombuild nog nodig ?
- Zijn Yum en Custombuild elkaars alternatieven of aanvullende tools ?

D) Backup
Een van de belangrijkste beheerklussen is backuppen.
Ik doe momenteel teveel backuppen
d1) ik backup met DA op Admin-level,
Hier worden ook de /etc, /home en /usr directories meegenomen.
Backup wordt geplaatst op de server in /home/admin/admin_backups/
Er is altijd slechts 1 -laatste- backup hier.
d2) ik backup met DA op Reseller-level
Backup wordt geplaatst op de server in /home/admin/user_backups/
Er is altijd slechts 1 -laatste- backup hier.
d3) er is iets wat ook backupped - ja, ik weet eigenlijk niet wie/wat dit doet-
Backup wordt geplaatst op de server in /home/backup/<datum>/
De backup bevat een /apache, /bind, /custom en /mysql directory.
En hier ontstond mijn probleem want de omvang van deze backups loopt dus wel op.
d4) Incidenteel maak ik een backup van de database mbv phpMyAdmin;Export
d5) de op de server geplaatste backupfiles doe ik ca wekelijks handmatig downloaden
mbv TotalCommander of WinSCP downloaden naar mn laptop.
Iemand een suggestie Wie/Wat de backups van d3) maakt ?
Iemand nog suggesties/tips inzake backups ?

E) Firewall
DA bevat een firewall, daar doe ik momenteel niets mee.

F) VPS-conditie monitoren
Ik doe periodiek de statistiek van de VPS bekijken (belasting CPU, throughput netwerk
en diskruimte, tenminste dat laatste dacht ik dus maar dat blijkt alleen de diskruimte van de site te zijn)

G) LAMP-conditie monitoren
Wellicht tips om de conditie van de LAMP-elementen te monitoren ?

H) Andere beheer suggesties ?
 
PHP hulp

PHP hulp

28/03/2024 20:46:04
 
Ward van der Put
Moderator

Ward van der Put

11/11/2017 13:47:09
Quote Anchor link
Waarvoor gebruik je de server? Als dat een bedrijfskritieke applicatie is, dan zou ik een managed VPS overwegen.
 
Aad B

Aad B

11/11/2017 14:49:08
Quote Anchor link
Doel van beheer is het uitsluiten of snel oplossen van incidenten/calamiteiten. Tegenwoordig is het met virtuele systemen zo dat het meest handige plan een plan is om je applicatie binnen een uur op een andere server in de lucht te hebben. In je lijstje staan grotendeels onbruikbare backups. Weersta de neiging om alles te backuppen. Incidenteel handmatig backuppen is vrijwel zinloos. Identificeer wat belangrijk is om dagelijks te backuppen en wat maandelijks of slechts incidenteel, bij wijziging, gebackupped moet worden. De tijd van machines backuppen is voorbij. Je zegt zelf een php script te hebben dat door een derde partij is gemaakt en wordt onderhouden. Zorg dat je ergens een backup hebt van de laatste versie, misschien ook wat html? Verder is het handig om kopieeen te hebben van diverse config files. Dat alles hoef je niet elke dag te backuppen. Zorg wel dat je zeer regelmatig een backup van MySQL data extern hebt. Ik gebruik zelf een hourly backup in een cyclus van 7 dagen. Na 7 dagen wordt de oudste overschreven vanwege naamgeving. Geen omkijken naar en ik kan 7 dagen terug op uurbasis. De backup gaat naar een ander systeem (Netwerkmount). Alles wordt gelogd en is aangesloten op logwatch die dagelijks in mijn mailbox komt. Ik heb een beheerdocumentje voor mezelf gemaakt waarmee ik in een uur op een nieuw systeem de zaak weer running heb.

Een begin: Hoe groot is je MySQL data? Maak bijvoorbeeld een cyclus van 1 dump per dag geef die dump de dagnaam zodat na 7 dagen de oudste overschreven wordt. Reken uit of je diskruimte voldoende is en je hebt geen omkijken naar volle disk risico's. Logwatch kan dagelijks de filesystemen rapporteren ter check voor jezelf.
Gewijzigd op 11/11/2017 14:57:00 door Aad B
 
John Joghems

John Joghems

11/11/2017 15:37:29
Quote Anchor link
Aad B op 11/11/2017 14:49:08:
Hoe groot is je MySQL data?


Mijn MySQL data is ca. 20MB.
Mijn complete site is ca. 1,5GB (90% daarvan zijn pictures).
Mijn disk is 100GB.
Toen ik recent een 'disk full' had kwam dat omdat er ca. 60 weekbackups waren opgeslagen.

> Logwatch kan dagelijks de filesystemen rapporteren ter check voor jezelf.
OK, Logwatch is een extra tool welke additioneel geinstalleerd kan worden begrijp ik.


Toevoeging op 11/11/2017 15:55:52:

Ward van der Put op 11/11/2017 13:47:09:
dan zou ik een managed VPS overwegen.

Tja, een terechte vraag
Allereerst zijn we hollanders en dus zien we op tegen de extra kosten.
Daarbij levert een site in het begin niets op en is het alleen een kostenpost.
Maar ook spelen mee...
* een managed VPS bevat meestal een software-set welke de ISP bepaald.
Voor mijn -betaalde- PHP-script
heb ik bv ioncube nodig
en dan reageert een ISP met .... dat valt niet onder onze support.
* Verder moet je voor het -betaalde- PHP-script toch ook zelf wat beheer doen, zoals mods aanbrengen.
* Daarbij speelt mee....
dat je wilt beginnen aan een nieuw traject met leeraspecten
en ik hoopte eigenlijk dat problemen mee zouden vallen en gering zullen zijn
en daarbij hoop ik zelf voldoende kennis hiervoor te ontwikkelen om beheer zelf te kunnen doen.

Maar de recente gebeurtenis zet me aan het denken om eea te heroverwegen ja....
Gewijzigd op 11/11/2017 17:40:46 door John Joghems
 
Aad B

Aad B

11/11/2017 20:23:42
Quote Anchor link
- Logwatch
kan je in ieder geval met Yum en wellicht ook met DA installeren.
- dat je wilt beginnen aan een nieuw traject met leeraspecten
Dan heb je nu een leermoment achter de rug, pak dit op en ontwerp een betere backup die (ook cyclisch gemaakt) op je systeem past. Je kan bijvoorbeeld dagelijks je database dumpen (mysqldump) en zippen en zo een gefixed aantal kopieeen bewaren. Als je je dump mysql_backup_maandag.zip t/m ....zondag.zip noemt heb je zeven veilige backups en loopt het nooit vol, maandag overschrijft de vorige maandag. Van de meer statische bestanden maak je eenmalig een backup en die bewaar je offsite. Kortom maak een veilig backupplan. Je backupplan was nu zodanig tot de bom barst. Al doende leert men hier kan je ook vragen over je OS en OS scripting stellen.
Gewijzigd op 11/11/2017 20:25:07 door Aad B
 
John Joghems

John Joghems

12/11/2017 03:13:53
Quote Anchor link
John Joghems op 11/11/2017 13:16:38:
d3) er is iets wat ook backupped - ja, ik weet eigenlijk niet wie/wat dit doet-
Backup wordt geplaatst op de server in /home/backup/<datum>/
En hier ontstond mijn probleem want de omvang van deze backups loopt dus wel op.

Gevonden!
Dit zijn de system-backups van DA.
http://www.domain.com:2222/CMD_SYSTEM_BACKUP
Maar omdat deze backup in een /<datum>/-directory wordt geplaatst
kun je gek genoeg niet voorkomen dat dit cumulatief oploopt.
Daarbij betekent dit dat je in DA op Admin-level dus 2 backup-mogelijkheden hebt.
Op DA-forum https://help.directadmin.com/item.php?id=269
lees je dat deze System-backup eigenlijk geen DA-backup is maar een link naar een sysbk-backup. Enfin, deze kan ik dus beter niet schedulen.


Toevoeging op 12/11/2017 04:38:14:

Aad B op 11/11/2017 20:23:42:
ontwerp een betere backup die (ook cyclisch gemaakt) op je systeem past.

Zie nu dat je in DA het save-path kunt appenden met een optie als <day of week> of <month nr>.
Dus nu een dagelijkse backup geschuled met <day of week> erbij
en een dagelijkse backup gescheduled met <month nr> erbij zodat ik 7 dag-backups en 12 maand-backups krijg.


Toevoeging op 12/11/2017 04:50:01:

Ward van der Put op 11/11/2017 13:47:09:
Als dat een bedrijfskritieke applicatie is, dan zou ik een managed VPS overwegen.

Vandaag had ik nog contact met ander computervrindje welke opperde: Waarom Start je geen 2e VPS ? 2x een Unmanaged VPS is goedkoper dan 1 managed VPS
en dan heb je geheel cleane config. waarop je je backup zet (heb je die ook weer getest) en dan overstapt op nieuwe VPS. Dan heb je wel ander IP-adres zodat je waarschijnlijk ca. 4 uur moet wachten op je DNS. Maar goed we werken allemaal weleens laat ;-)
Iemand een reactie inzake 2x unmanaged VPS versus 1x managed-VPS ?
Gewijzigd op 12/11/2017 04:33:03 door John Joghems
 
Ben van Velzen

Ben van Velzen

12/11/2017 11:16:51
Quote Anchor link
2x unmanaged VPS vs 1x managed is een overweging, als je weet waar je mee bezig bent. Hoe duur denk je dat tickets naar je hosting worden als je keer op keer buiten contracten om door je hoster de poep laat wegscheppen? Als het een keer gebeurt strijken ze vaak nog wel over hun hart, maar ook echt niet vaker dan dat.

Daar zit je probleem ook, je hebt een unmanaged VPS zonder dat je een idee hebt over monitoring, of wat dat betreft het oplossen van (nog niet eens zo heel grote) problemen. Dan is de keuze snel gemaakt.
 
- Ariën  -
Beheerder

- Ariën -

12/11/2017 11:26:47
Quote Anchor link
John Joghems op 11/11/2017 13:16:38:
C) Software beheer tools
Ik heb dus sw geinstalleerd mbv yum
en iemand heeft ook al Custombuild2 geroepen
maar hier zit dus een kennishiaat bij mij.
- Als je een Controlpanel als DA gebruikt is dan iets als yum of Custombuild nog nodig ?
- Zijn Yum en Custombuild elkaars alternatieven of aanvullende tools ?

De Custombuild moet je zien als deels vervanger en verlengstuk voor yum bij de standaard packages die DirectAdmin gebruikt (apache, nginx, mysql, mariadb, exim,en nog een paar). Het zorgt ervoor dat je bij het installeren van de packages volgens ./build <package-naam>, dat deze op de juiste wijze geinstalleerd en geconfigureerd worden, zodat DirectAdmin er direct mee kan werken. Er zijn natuurlijk een aantal mensen die beweren dat DirectAdmin niet de juiste weg hiermee is ingeslagen, maar ze hebben wel zelf controle over de nodige packages. Mocht er een rotte versie tussen zetten, dan kunnen ze die ook offline trekken als het nodig is.
Gewijzigd op 12/11/2017 11:27:29 door - Ariën -
 
John Joghems

John Joghems

12/11/2017 12:47:42
Quote Anchor link
Even over managed-VPS
Ik heb -bij een andere ISP- daar ooit ervaring mee gehad.
Daar kreeg ik niet eens inloginfo voor een SSH-connectie.
zodat ik zelf geen extra's als bv ioncube kon toevoegen.
Zelfs php.ini mutaties moest ik vragen.
Wat dat betreft ben ik bij unmanaged-VPS nimmer tegen dichte deuren aan gelopen.

Daarbij speelde mee dat ik op een bepaald momente al 3 jaar lang die managed-VPS had
maar dat het pakket wat ik had al niet meer verkocht werd.
Ik kreeg de indruk dat mijn VPS minder aandacht kreeg.
Ook wat dat betreft lijkt me 1/jr een VPS opnieuw opbouwen nog niet verkeerd.
 
Aad B

Aad B

12/11/2017 14:04:33
Quote Anchor link
Er is nogal wat bagger op de markt, managed en unmanaged. Het grootste probleem is de reseller van de reseller van de reseller en dan daar weer de seller van. Dat is een soort wildgroei die je niet wenst. Daar ontstaan ook al die regeltjes van geen ssh, geen config files wijzigen etc etc. Omdat veel resellers van resellers ook eigenlijk geen verstand hebben van bijvoorbeeld de ins en out van Linux is het allemaal vaak erg fragiel en erg restricted uit angst dat het product crashed. Kortom, er gaat niks boven een unmanaged VPS zo dicht mogelijk bij de eerste leverancier en niet bij de reseller van de reseller. Huur eenmalig wat expertise in om je systeem robuust te maken en te documenteren met tips en trucs waarvan je kan leren zodat je zelf verder kan. Valkuilen als vollopende disken moeten op voorhand uitgesloten worden. Steek wat energie in zelfstudie en je leert al doende.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.