Lydmaskinen server setup
Lydmaskinen server setup
Grundlæggende
Som truet med tidligere, så kommer her den liste af udstyr jeg har compilet med @Hippo .
Vi kommer til at køre Lydmaskinen samt mine andre websites fra dette setup. I første omgang er det mine egne overlevende websites, som bliver flyttet først, da det er lidt mere tricky at flytte Lydmaskinen.
Har man erfaring med server setups og måske en forståelse af hvad vi gerne vil og har brug for (eller ikke brug for), så modtages kommentarer gerne.
Både bekræftende og det modsatte, hvis vi har overset noget.
Måske lidt overkill til det behov vi har, men jeg betragter det som nødvendigt psykologisk og terapeutisk selvforsvar efter det triste forløb med OVH.
Desuden burde Lydmaskinen komme til at køre en del hurtigere med dette dedikerede setup og det er jo aldrig dårligt.
Serverrum Skitse over serverrummet, som bliver i kælderen under hovedhuset (lige under router-skabet på førstesalen, hvor fiber indtaget også kommer fra) et sikkert og tørt sted og med ventilation. Nordside og køligt i forvejen.
Temperaturmål er omkring 25 C og ikke højere end 27-28 C.
Opsætning
Hippo må lige støde til her, men som jeg har forstået det kommer vi til at køre således her:
1/1 Gbit erhvervsfiber ind.
Ubuntu/Xen Hypervisor på HPE serveren som dom0 og hardware virtualized machine domU'er i form af 1 x VM til Lydmaskinen for sig, 1 x VM til Online Mastering o.a., 1 x VM til WordPress o.a. for sikkerhedens skyld.
Disse VM'er kører Ubuntu med LAMP stacks.
Dertil en VM med Nginx som agerer reverse proxy, fordi jeg umiddelbart kun kan få 1 statisk IP (sandsynligvis, men det afhænger af hvilken erhvervsfiber jeg kan få).
Foran sidder en kraftig hardware firewall med pfSense og en SFP+ switch.
I røven sidder en NAS til backup, samt rsync backup hos Hippo, som også rsyncer hos mig. Derfor de rigelige bays i NAS'en. Så er vi sikret, hvis noget brænder af/sammen lokalt.
Så er der nogle detaljer i forhold til at afskærme dele af mit private netværk, studiets netværk osv. som foregår i en anden router.
Det hele er rackmountet og powered af en UPS, som får batteri skiftet i hvert fald hver 4. år. Der er temperaturmåler og brandalarm i form af trådløs/netværket Ajax FireProtect i rummet.
Udstyrslisten findes i den vedhæftede PDF. Frem med luppen I videst muligt omfang har vi valgt enterprise kvalitet.
Som truet med tidligere, så kommer her den liste af udstyr jeg har compilet med @Hippo .
Vi kommer til at køre Lydmaskinen samt mine andre websites fra dette setup. I første omgang er det mine egne overlevende websites, som bliver flyttet først, da det er lidt mere tricky at flytte Lydmaskinen.
Har man erfaring med server setups og måske en forståelse af hvad vi gerne vil og har brug for (eller ikke brug for), så modtages kommentarer gerne.
Både bekræftende og det modsatte, hvis vi har overset noget.
Måske lidt overkill til det behov vi har, men jeg betragter det som nødvendigt psykologisk og terapeutisk selvforsvar efter det triste forløb med OVH.
Desuden burde Lydmaskinen komme til at køre en del hurtigere med dette dedikerede setup og det er jo aldrig dårligt.
Serverrum Skitse over serverrummet, som bliver i kælderen under hovedhuset (lige under router-skabet på førstesalen, hvor fiber indtaget også kommer fra) et sikkert og tørt sted og med ventilation. Nordside og køligt i forvejen.
Temperaturmål er omkring 25 C og ikke højere end 27-28 C.
Opsætning
Hippo må lige støde til her, men som jeg har forstået det kommer vi til at køre således her:
1/1 Gbit erhvervsfiber ind.
Ubuntu/Xen Hypervisor på HPE serveren som dom0 og hardware virtualized machine domU'er i form af 1 x VM til Lydmaskinen for sig, 1 x VM til Online Mastering o.a., 1 x VM til WordPress o.a. for sikkerhedens skyld.
Disse VM'er kører Ubuntu med LAMP stacks.
Dertil en VM med Nginx som agerer reverse proxy, fordi jeg umiddelbart kun kan få 1 statisk IP (sandsynligvis, men det afhænger af hvilken erhvervsfiber jeg kan få).
Foran sidder en kraftig hardware firewall med pfSense og en SFP+ switch.
I røven sidder en NAS til backup, samt rsync backup hos Hippo, som også rsyncer hos mig. Derfor de rigelige bays i NAS'en. Så er vi sikret, hvis noget brænder af/sammen lokalt.
Så er der nogle detaljer i forhold til at afskærme dele af mit private netværk, studiets netværk osv. som foregår i en anden router.
Det hele er rackmountet og powered af en UPS, som får batteri skiftet i hvert fald hver 4. år. Der er temperaturmåler og brandalarm i form af trådløs/netværket Ajax FireProtect i rummet.
Udstyrslisten findes i den vedhæftede PDF. Frem med luppen I videst muligt omfang har vi valgt enterprise kvalitet.
- Vedhæftede filer
-
- server-01.pdf
- (2.67 MiB) Downloadet 54 gange
Stol ikke på at din backup virker.
Test at din backup virker.
Test at din backup virker.
Jeg laver også gratis plugins: www.robotplanet.dk/audio_plugins
Right, det var ikke et dårligt tip, fortiden taget i betragtning Jeg ved ikke så meget om at teste backupintegritet (udover helt banalt), men det ved jeg andre ved noget om herinde i praksis.
Altså i de setup jeg har med at gøre på arbejdet, har vi fuldt spejlede data online på separate sites, og tester ved at switche fra det ene site the det andet. Derudover er der backups, som også testes jævnligt. Vi finder og retter jævnligt fejl og uhensigtsmæssigheder.
De mest avancerede setup jeg har hørt om, havde tre sites, der alle alene kunne klare loaden, og så to backup-sties. De skiftede primært site hver måned.
Det er nok ikke relevant til websites - uanset hvor vigtige de måtte være
--
Robert
Robert
Du er med på, at der udover rsync sidder en QNAP NAS med to enterprise diske og laver lokal backup? Eller mente du noget andet.
Meget interessant. Hvordan gøres dette i praksis, dvs. er disse sites interne eller skjulte?Pastorius skrev: ↑fre 16. apr 2021 23:03 Altså i de setup jeg har med at gøre på arbejdet, har vi fuldt spejlede data online på separate sites, og tester ved at switche fra det ene site the det andet. Derudover er der backups, som også testes jævnligt. Vi finder og retter jævnligt fejl og uhensigtsmæssigheder.
De mest avancerede setup jeg har hørt om, havde tre sites, der alle alene kunne klare loaden, og så to backup-sties. De skiftede primært site hver måned.
Det er nok ikke relevant til websites - uanset hvor vigtige de måtte være
Sites=maskinstuer med kraftige fiberforbindelser imellem.Holger skrev: ↑fre 16. apr 2021 23:38Meget interessant. Hvordan gøres dette i praksis, dvs. er disse sites interne eller skjulte?Pastorius skrev: ↑fre 16. apr 2021 23:03 Altså i de setup jeg har med at gøre på arbejdet, har vi fuldt spejlede data online på separate sites, og tester ved at switche fra det ene site the det andet. Derudover er der backups, som også testes jævnligt. Vi finder og retter jævnligt fejl og uhensigtsmæssigheder.
De mest avancerede setup jeg har hørt om, havde tre sites, der alle alene kunne klare loaden, og så to backup-sties. De skiftede primært site hver måned.
Det er nok ikke relevant til websites - uanset hvor vigtige de måtte være
Det kører på IBM-Mainframes med en teknologi kaldet GDPS, der ud over at holde styr på at data er i sync, også sender svar tilbage til applikationerne når den er i kontrol, så man altid ved hvor man er. Det bruges mest i finansverden, og håndterer mange millioner transaktioner pr. sekund.
Kravene til dataintegritet, kryptering etc er skruet voldsomt op de senere år. Udover egne test, bliver vi revideret af kundernes revisorer og interne revisorer.
--
Robert
Robert
Mainframes kan også hoste fx Linusmaskiner (KDM kan køre direkte på HW) eller Open shift etc. Man kan lave nogle ret vilde maskiner.Pastorius skrev: ↑fre 16. apr 2021 23:57Sites=maskinstuer med kraftige fiberforbindelser imellem.Holger skrev: ↑fre 16. apr 2021 23:38Meget interessant. Hvordan gøres dette i praksis, dvs. er disse sites interne eller skjulte?Pastorius skrev: ↑fre 16. apr 2021 23:03 Altså i de setup jeg har med at gøre på arbejdet, har vi fuldt spejlede data online på separate sites, og tester ved at switche fra det ene site the det andet. Derudover er der backups, som også testes jævnligt. Vi finder og retter jævnligt fejl og uhensigtsmæssigheder.
De mest avancerede setup jeg har hørt om, havde tre sites, der alle alene kunne klare loaden, og så to backup-sties. De skiftede primært site hver måned.
Det er nok ikke relevant til websites - uanset hvor vigtige de måtte være
Det kører på IBM-Mainframes med en teknologi kaldet GDPS, der ud over at holde styr på at data er i sync, også sender svar tilbage til applikationerne når den er i kontrol, så man altid ved hvor man er. Det bruges mest i finansverden, og håndterer mange millioner transaktioner pr. sekund.
Kravene til dataintegritet, kryptering etc er skruet voldsomt op de senere år. Udover egne test, bliver vi revideret af kundernes revisorer og interne revisorer.
Sidste jeg hørte efter - det er nogle år siden - kunne man allokere 2TB RAM til én Linuxbox. Mange kan også have ret mange kerner, men de behøver ikke være interne, så man kan lave en mangekernet maskine, hvor styresystemet kun kan se en kerne, mens maskinen selv sender load til ekstra kerner. Det var smart ift flere meget dyre licenser, baseret på. antal kerner. De fleste SW-firmaer har dog luret den, og fundet på andre licensbetingelser
--
Robert
Robert
Den her manual er fra 60'erne, men i princippet er der ingen forskel - programmerne fra dengang kan stadig køre.Pastorius skrev: ↑lør 17. apr 2021 00:03Mainframes kan også hoste fx Linusmaskiner (KDM kan køre direkte på HW) eller Open shift etc. Man kan lave nogle ret vilde maskiner.Pastorius skrev: ↑fre 16. apr 2021 23:57Sites=maskinstuer med kraftige fiberforbindelser imellem.
Det kører på IBM-Mainframes med en teknologi kaldet GDPS, der ud over at holde styr på at data er i sync, også sender svar tilbage til applikationerne når den er i kontrol, så man altid ved hvor man er. Det bruges mest i finansverden, og håndterer mange millioner transaktioner pr. sekund.
Kravene til dataintegritet, kryptering etc er skruet voldsomt op de senere år. Udover egne test, bliver vi revideret af kundernes revisorer og interne revisorer.
Sidste jeg hørte efter - det er nogle år siden - kunne man allokere 2TB RAM til én Linuxbox. Mange kan også have ret mange kerner, men de behøver ikke være interne, så man kan lave en mangekernet maskine, hvor styresystemet kun kan se en kerne, mens maskinen selv sender load til ekstra kerner. Det var smart ift flere meget dyre licenser, baseret på. antal kerner. De fleste SW-firmaer har dog luret den, og fundet på andre licensbetingelser
På mit tidligere arbejde, fandt vi for et par år siden en alvorlig fejl i et program, der under særlige omstændigheder (som så opstod i 2018) kunne medføre et loop. Programmet var sidst rettet 18. juni 1992 (programmøren har sikkert haft travlt med at komme hjem og se fodbold)
Vi støder også stadig på år 2000-problemer ind imellem. Senest fangede vi en fejl (i 2017) som ville have gjort at 18-årige - fødselsår 00) ikke kunne optage løn pr. 1/1, hvis ikke det var blevet rettet.
https://www.dropbox.com/s/iyxadlgtn8yka ... 0.pdf?dl=0
--
Robert
Robert
Fandt en lille video, der giver et overblik:Pastorius skrev: ↑lør 17. apr 2021 00:12Den her manual er fra 60'erne, men i princippet er der ingen forskel - programmerne fra dengang kan stadig køre.Pastorius skrev: ↑lør 17. apr 2021 00:03Mainframes kan også hoste fx Linusmaskiner (KDM kan køre direkte på HW) eller Open shift etc. Man kan lave nogle ret vilde maskiner.Pastorius skrev: ↑fre 16. apr 2021 23:57
Sites=maskinstuer med kraftige fiberforbindelser imellem.
Det kører på IBM-Mainframes med en teknologi kaldet GDPS, der ud over at holde styr på at data er i sync, også sender svar tilbage til applikationerne når den er i kontrol, så man altid ved hvor man er. Det bruges mest i finansverden, og håndterer mange millioner transaktioner pr. sekund.
Kravene til dataintegritet, kryptering etc er skruet voldsomt op de senere år. Udover egne test, bliver vi revideret af kundernes revisorer og interne revisorer.
Sidste jeg hørte efter - det er nogle år siden - kunne man allokere 2TB RAM til én Linuxbox. Mange kan også have ret mange kerner, men de behøver ikke være interne, så man kan lave en mangekernet maskine, hvor styresystemet kun kan se en kerne, mens maskinen selv sender load til ekstra kerner. Det var smart ift flere meget dyre licenser, baseret på. antal kerner. De fleste SW-firmaer har dog luret den, og fundet på andre licensbetingelser
På mit tidligere arbejde, fandt vi for et par år siden en alvorlig fejl i et program, der under særlige omstændigheder (som så opstod i 2018) kunne medføre et loop. Programmet var sidst rettet 18. juni 1992 (programmøren har sikkert haft travlt med at komme hjem og se fodbold)
Vi støder også stadig på år 2000-problemer ind imellem. Senest fangede vi en fejl (i 2017) som ville have gjort at 18-årige - fødselsår 00) ikke kunne optage løn pr. 1/1, hvis ikke det var blevet rettet.
https://www.dropbox.com/s/iyxadlgtn8yka ... 0.pdf?dl=0
https://www.coursera.org/lecture/enterp ... el-4-8ltC1
Det er nok lidt svært at forstå fra scratch.
--
Robert
Robert
- Søren Steinmetz
- Medlem
- Indlæg: 268
- Sted: Gislinge området
Test af om backup virker kan evt klares med, at du har en kopi af f.eks. lydmaskinens Ubuntu server (med anden IP naturligvis), som du kan starte op og teste en recover af backup på.
Jeg ved godt det er smartest med et komplet test setup, men måske lige i overkanten at have dublerede servere hjemme.
edit:
Så lige du har valgt en CRS309 10Gbit switch, men ikke skrevet SFP moduler på.
Resten af dit udstyr er "kun" 1Gbit, så der skal laves lidt på den front.
Jeg ved godt det er smartest med et komplet test setup, men måske lige i overkanten at have dublerede servere hjemme.
edit:
Så lige du har valgt en CRS309 10Gbit switch, men ikke skrevet SFP moduler på.
Resten af dit udstyr er "kun" 1Gbit, så der skal laves lidt på den front.