Likes Likes:  0
Resultaten 1 tot 15 van de 17
Pagina 1 van de 2 1 2 LaatsteLaatste
Geen
  1. #1
    Poor man's availability cluster
    geregistreerd gebruiker
    26 Berichten
    Ingeschreven
    26/10/08

    Locatie
    Bunnik

    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    0 Berichten zijn liked


    Registrar SIDN: nee
    KvK nummer: nvt
    Ondernemingsnummer: nvt

    Thread Starter

    Poor man's availability cluster

    Beste,

    Voor een hosted logging applicatie heb ik een zeer hoge availability nodig, waar 'de service' liefst geen minuut downtime heeft. Nu lijkt mij dat je dat met 1 server niet kunt bereiken, dus heb je al gauw meerdere servers in verschillende racks/datacenters nodig om het risico van server- / netwerkproblemen te spreiden. Op het moment dat de service er (als geheel) uit ligt merken klanten dit namelijk gelijk door een gat in hun statistieken.

    Nu is het loggen van data niet echt een CPU / memory intensieve taak. Ik heb het programma zo geschreven dat er enkel SELECT (op prim keys) / INSERT queries naar de database gaan, dus de queries zijn doodeenvoudig en zouden de CPU en HDD voornamelijk laten idle-n. De verwachtte read:write verhouding is resp. 1:1000.

    Nu wil ik op het oog van de kosten niet voor dedicated servers gaan, maar voor (een groeiend aantal) VPS accounts, daar deze over het algemeen over veel betere hardware beschikken (en 'dus' uptime) dan voor dat geld zelf samen te stellen / te huren is.

    Nu is de hele applicatie technisch doodeenvoudig: inkomende HTTP data parsen en direct de DB in. Af en toe wordt enkele uren oude data uit de DB gewipt en sterk compressed als bestandje weggeschreven (of als binary data weer de DB in). Deze 'chunks' worden tussen de nodes verspreid.

    Tot zover mijn plannen. Is een dergelijk ontwerp geschikt? Is het een goed idee om zo'n high availability service te draaien op een vloot VPS accounts met goede hardware (minimaal RAID1, ECC RAM, Xeon CPUs) ? Of zouden jullie dit helemaal anders doen. Let wel, budget is beperkt (<100e/m) zolang de service geen groot klantenbestand kent.

  2. #2
    Poor man's availability cluster
    geregistreerd gebruiker
    793 Berichten
    Ingeschreven
    18/04/08

    Locatie
    België

    Post Thanks / Like
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    9 Berichten zijn liked


    Naam: Alain Van Messen
    Bedrijf: Evoluto
    Functie: Zaakvoerder
    URL: www.evoluto.be
    Ondernemingsnummer: 564814865
    View https://www.linkedin.com/company/evoluto's profile on LinkedIn

    Hangt natuurlijk ook af van de verdere specs die je hebt !
    Voor een 100-tal Euro per maand geraakt je wel rond met
    twee VPSen, dedicated wordt dit al wat moeilijker ...

  3. #3
    Poor man's availability cluster
    geregistreerd gebruiker
    26 Berichten
    Ingeschreven
    26/10/08

    Locatie
    Bunnik

    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    0 Berichten zijn liked


    Registrar SIDN: nee
    KvK nummer: nvt
    Ondernemingsnummer: nvt

    Thread Starter
    Ik verwacht dat een VPS van 256MB RAM, ~5GB HDD en 50GB traffic al meer dan genoeg is. Ik denk dat ik net 3 VPS accounts kan hebben voor dat geld: 2x normaal (40 euro) en 1x budget (20 euro) als 'last resort'.

    Verder natuurlijk Linux.

    Welke specs zijn er nog meer relevant?

  4. #4
    Poor man's availability cluster
    geregistreerd gebruiker
    793 Berichten
    Ingeschreven
    18/04/08

    Locatie
    België

    Post Thanks / Like
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    9 Berichten zijn liked


    Naam: Alain Van Messen
    Bedrijf: Evoluto
    Functie: Zaakvoerder
    URL: www.evoluto.be
    Ondernemingsnummer: 564814865
    View https://www.linkedin.com/company/evoluto's profile on LinkedIn

    Al meer dan genoeg denk ik, misschien een post
    plaatsen in de "Aanbiedingen gezocht" sectie !?


  5. #5
    Poor man's availability cluster
    geregistreerd gebruiker
    26 Berichten
    Ingeschreven
    26/10/08

    Locatie
    Bunnik

    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    0 Berichten zijn liked


    Registrar SIDN: nee
    KvK nummer: nvt
    Ondernemingsnummer: nvt

    Thread Starter
    Ik ben deze thread eigenlijk meer begonnen om feedback te krijgen op het plan.

    Mag ik aannemen - aangezien jullie al aan de volgende stap denken - dat het met het ontwerp wel snor zit?

  6. #6
    Poor man's availability cluster
    Internet Services
    3.200 Berichten
    Ingeschreven
    27/03/06

    Locatie
    Utrecht

    Post Thanks / Like
    Mentioned
    14 Post(s)
    Tagged
    0 Thread(s)
    43 Berichten zijn liked


    Naam: Jeroen
    View nl.linkedin.com/in/jeroenvheugten's profile on LinkedIn

    En hoe had je het redunant maken in gedachten dan? Ik bedoel hoe wil je gaan zorgen dat als server A offline is, server B de taken overneemt?

    Bovendien vind ik het plan een paar budget vpssen te huren bijzonder slecht. Dan kan je beter 1 goede (met SLA's) vps huren van een gerenommeerd hostingbedrijf (en netwerk).

  7. #7
    Poor man's availability cluster
    geregistreerd gebruiker
    26 Berichten
    Ingeschreven
    26/10/08

    Locatie
    Bunnik

    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    0 Berichten zijn liked


    Registrar SIDN: nee
    KvK nummer: nvt
    Ondernemingsnummer: nvt

    Thread Starter
    Client X doet een request naar A. Bij een timeout/error doet X een connect naar B, daarna C, D, etc...

    Er zit dus een klein beetje intelligentie in de client, da's misschien het zwakke punt.

    Ik zat ook te denken aan een systeem als een loadbalancer, maar dan met maar 1 target (bijv. A), tot die ermee uit scheidt, waarna alle traffic naar B doorgestuurd wordt. Voordeel is dat de client maar met 1 IP hoeft te communiceren, nadeel is dat als de loadbalancer/proxy(?) eruit ligt je geen fallback hebt.

  8. #8
    Poor man's availability cluster
    geregistreerd gebruiker
    793 Berichten
    Ingeschreven
    18/04/08

    Locatie
    België

    Post Thanks / Like
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    9 Berichten zijn liked


    Naam: Alain Van Messen
    Bedrijf: Evoluto
    Functie: Zaakvoerder
    URL: www.evoluto.be
    Ondernemingsnummer: 564814865
    View https://www.linkedin.com/company/evoluto's profile on LinkedIn

    High-availability onder linux is voor twee
    machines, verbonden met een LAN of een
    crossed cable bvb, de ene machine is dan
    backup voor de andere.

    Info op http://www.linux-ha.org

    Je zou dit op VPS basis ook kunnen doen
    maar dan zit je waarschijnlijk op dezelfde
    server of netwerk en dan moet je een 2de
    virtual NIC hebben om de twee VPSen aan
    mekaar te verbinden.

    Het klinkt ernaar dat de intelligentie in de
    client zal moeten zitten.

    Heb zelf met high-availability zitten spelen
    in een firewall concept, onder OpenBSD met
    CARP (proprietary protocol). Hoop dat je wat
    interessante input krijgt van anderen, meer in
    verband met jouw specifieke project !




  9. #9
    Poor man's availability cluster
    geregistreerd gebruiker
    21 Berichten
    Ingeschreven
    17/01/08

    Locatie
    Dordrecht

    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    0 Berichten zijn liked


    Registrar SIDN: nee
    KvK nummer: 23087694
    Ondernemingsnummer: nvt

    Wat in een hele andere hoek zit maar misschien nog interessant is om te overwegen:
    Amazon EC2 icm Amazon S3. Amazon EC2 is een cloud computing dienst die je in staat stelt om "instant" VPS-en aan te maken die achteraf gefactureerd worden op basis van daadwerkelijk aantal uren gebruik. Het handige in jouw situatie is dat je zelf kan beslissen in welk Amazon datacentrum (verspreid over de hele wereld) je jouw VPS wilt hebben.
    Zodra het VPS is aangemaakt kun je ook intern via een web interface/ API IP's omrouten.

    Omdat alles dus ook via de API te benaderen is zou je mbv scripts automatisch je applicatie in een nieuwe VPS op een ander continent kunnen starten zodat 1 VPS down gaat. Het voordeel hiervan is dat je niet dubbel betaald voor een VPS dat je toch niet gebruikt. Nadeel dat een VPS oplossing waarschijnlijk goedkoper is.

    Er zijn overigens ook bedrijven die de scripts voor High Availability op basis van Amazon EC2 geschreven hebben en netjes gebundeld hebben in een web interface. Hier zijn echter wel kosten aan verbonden. Voorbeelden zijn RightScale en Scalr (https://scalr.net/login.php). Van Scalr is een deel ook open source: http://code.google.com/p/scalr/

  10. #10
    Poor man's availability cluster
    geregistreerd gebruiker
    6.040 Berichten
    Ingeschreven
    23/10/04

    Locatie
    Amsterdam

    Post Thanks / Like
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    171 Berichten zijn liked


    Functie: Systems Engineer
    URL: weblog.aklmedia.nl
    View randytenhave's profile on LinkedIn

    Een hoop mensen roepen hier alweer wat, maar op basis van wat werkt de logging applicatie: Java / J2EE i.c.m. bijvooorbeeld Apache Tomcat of welk platform wil je gebruiken?

  11. #11
    Poor man's availability cluster
    geregistreerd gebruiker
    26 Berichten
    Ingeschreven
    26/10/08

    Locatie
    Bunnik

    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    0 Berichten zijn liked


    Registrar SIDN: nee
    KvK nummer: nvt
    Ondernemingsnummer: nvt

    Thread Starter
    Het is inderdaad geschreven in Java. De applicatie draait niet binnen een framework, het is simpelweg Java SE met wat eigen classes. Het technische deel is zo idioot simpel dat ik al die overhead van J2EE niet wil. Ik heb een eigen op Java NIO gebaseerde HTTP/1.1 server geschreven, die zich al bewezen heeft in een productie omgeving met een uptime van enkele maanden.

    Over elke verbinding komen meerdere requests binnen, die na het parsen en valideren vrijwel 1-op-1 in een MySQL database terecht komen. Het is allemaal zo eenvoudig dat ik denk dat een PIII al zou staan te niksen.

    Het is dus allemaal extreem licht van opzet, de JRE heeft een heap van 64MB of minder (!). Het enige wat performance eist is het af en toe leeg trekken van de DB, comprimeren, en opslaan van dat 'archief'.

    Het 'echte' werk, gebeurt in een desktop app die die archieven van de server trekt en er, met behulp van 101 filters, grafieken en tabellen uit tovert.

    Ik zou waarschijnlijk toe kunnen met een VPS van 128MB, maar om onverhoopt niet te gaan swappen lijkt 256MB een veiligere keuze. Serverside zijn er dus bijna geen eisen, als de boel maar in de lucht blijft om de data binnen te halen.
    Laatst gewijzigd door Riven; 02/11/08 om 22:55.

  12. #12
    Poor man's availability cluster
    geregistreerd gebruiker
    254 Berichten
    Ingeschreven
    01/02/05

    Locatie
    Den Haag

    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    0 Berichten zijn liked


    Registrar SIDN: Nee
    KvK nummer: nvt
    Ondernemingsnummer: nvt

    Trouwens, je stelt dat de writes minder belasting dan een read opleveren. Vaak is het juist andersom, omdat de reads vaak direct uit het geheugen kunnen worden gedaan, wat geen i/o (=traag) aktie tot gevolg heeft. Zeker budget vps'en hebben vaak limieten op het aantal i/o bewerkingen, en als je dus veel i/o hebt (wat je dus hebt omdat je steeds writes doet) is het wel zaak om rekening mee te houden dat je niet een vps krijgt waar z'n beperking op zit.

    Opzich je idee is goed, maar is het niet eenvoudiger om je nodes allemaal dezelfde data te laten lezen en per node alle data te hebben? ipv het rondedelen, heb je bv 3 nodes met alle data. De kans dat alle 3 down zijn is dan een stuk kleiner?

  13. #13
    Poor man's availability cluster
    moderator
    4.784 Berichten
    Ingeschreven
    04/11/05

    Locatie
    Gent

    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    12 Berichten zijn liked


    Registrar SIDN: ja
    KvK nummer: nvt
    Ondernemingsnummer: 0475284162

    hiervoor raad ik je aan om toch even je plan voor te leggen aan een hoster met ervaring. Hoe ga je bvb databases syncroon houden over de verschillende locaties, en wat als er eentje offline gegaan is, en die komt terug? Waar zit de "hoofd"-databank?

    Het is perfect mogelijk om dit uit te bouwen, en aangezien je de client-kant en de server-kant beheert is het mogelijk om allerlei oplossingen in te bouwen, maar het gaat niet lukken met een budgetje van 100 euro per maand.

  14. #14
    Poor man's availability cluster
    geregistreerd gebruiker
    26 Berichten
    Ingeschreven
    26/10/08

    Locatie
    Bunnik

    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    0 Berichten zijn liked


    Registrar SIDN: nee
    KvK nummer: nvt
    Ondernemingsnummer: nvt

    Thread Starter
    Er is inderdaad een synchronisatie probleem, als er 1 node uitvalt. Er is een kans dat een deel van de data verloren gaat, als de node echt stuk is - oplossing daarvoor is om data altijd naar minstens 2 actieve (random) nodes te sturen. In alle andere gevallen komt de node weer online, en gaat weer zijn data vergelijken met de andere nodes, waarna bij beiden de ontbrekende delen aangevuld worden. Er is dus geen master/slave relatie. Iedere node vult bij een ander aan wat hij wel heeft en de ander niet.

    Het gaat hier niet om het synchroniseren van een database, maar om de 'archieven' (data uit de database van 1-2uur oud). Dit zijn bestandjes van minder dan 1MB en kunnen snel rondgestuurd worden. Bestandjes kunnen ge-merged worden met bestandjes van diezelfde periode van een andere server. Uiteindelijk heb je dus een reeks bestandjes die - als ze meer dan 2 uur oud zijn, nooit meer zullen veranderen (mits alle nodes up zijn). Het synchroon houden hiervan is eenvoudig.

    Ik heb dus een soort P2P systeem in gedachten van 3+ servers die constant met elkaar communiceren en waarbij met een kleine vertraging op alle nodes uiteindelijk dezelfde data staat.

    Wat ik mij nog afvraag is hoe betrouwbaar/stabiel een proxy nou eigenlijk kan zijn. Ik heb het niet zo op een single-point-of-failure, maar uiteindelijk hebben alle sites hiermee te maken. Waarschijnlijk maak ik me te druk om de stabiliteit van de frontend, en ligt de kunst van het online houden van de service eerder bij de cluster backend. De frontend heb je 'zo' vervangen met een DNS wijziging, waarna de cluster weer zijn ding doet. Ik ben als devver vooral gericht op software (als het werkt, werkt het) maar in de afgelopen tijd ben ik me uit pure noodzaak ook met systeembeheer bezig gaan houden waar naar mijn ervaring hele andere regels gelden. Ik ben vooral geinteresseerd hoe ik voor die paar centen en een goed ontwerp toch een stabiel systeem kan krijgen met een streven van >99.9% uptime.

  15. #15
    Poor man's availability cluster
    moderator
    7.022 Berichten
    Ingeschreven
    29/07/03

    Locatie
    Nijmegen

    Post Thanks / Like
    Mentioned
    12 Post(s)
    Tagged
    0 Thread(s)
    175 Berichten zijn liked


    Naam: Mike
    Bedrijf: admin.nu
    URL: www.admin.nu
    Registrar SIDN: Ja
    KvK nummer: 09139651

    afhankelijk om hoeveel data het gaat, maar drdb is prima in staat om over het netwerk data synchroom te houden.
    "Zo zijn ook wij één leverancier. Dé leverancier in gedegen Linux kennis, wanneer jij dat nodig hebt."
    Boek je admin vandaag nog via : www.admin.nu
    Gevestigd in Nederland en Moldavië

    Lees hier de webhostingtalk.nl forum regels en voorwaarden!

Pagina 1 van de 2 1 2 LaatsteLaatste

Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2018 Webhostingtalk.nl.
Web Statistics