Likes Likes:  0
Resultaten 1 tot 3 van de 3

Onderwerp: Ceph - disk keuze

  1. #1
    Ceph - disk keuze
    geregistreerd gebruiker
    1.086 Berichten
    Ingeschreven
    30/04/09

    Locatie
    NL

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


    KvK nummer: 51985977

    Thread Starter

    Ceph - disk keuze

    Wij hebben een Ceph cluster draaien welke SSD Only is, echter is dit vrij prijzig. Naast de SSD Only pool, willen we een goedkopere pool opzetten maar willen niet teveel inleveren kwa prestaties.

    Ik zie hiervoor 2 (of eigenlijk 3) mogelijkheden:
    - SATA schijven met colocated journal op SSD, ratio van 4:1.
    - SAS schijven met colocated journal op SSD, ratio van 4:1.
    - SAS schijven met dedicated journal.

    BIj de eerste optie denk ik dat een colocated SSD journal voor prestatiewinst zal zorgen, echter denk ik dat we door gebruik te maken van SATA disken teveel in performance zullen inleveren. Daarom dus optie 2 en 3.

    Bij optie 2 ben ik bang dat de SSD de bottleneck gaat vormen, maar misschien ook niet? Iemand ervaring met bovenstaande opties?

    Daarnaast, welke merk/type/model disken raden jullie aan? Moet 2.5" zijn.

  2. #2
    Ceph - disk keuze
    geregistreerd gebruiker
    1.892 Berichten
    Ingeschreven
    17/08/05

    Locatie
    Amsterdam

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


    Naam: Wieger Bontekoe
    Bedrijf: Skynet ICT B.V.
    Functie: CEO
    URL: skynet-ict.nl
    Registrar SIDN: Nee
    View wbontekoe's profile on LinkedIn

    Hoeveel disken heb je en in het nieuwe scenario hoeveel disken krijg je. De snelheid van de disks alleen bepaald de snelheid niet. Ook kun je kijken naar SSD write cache. Het journal doet in elk geval aan IO niets dus dat scheiden zal amper wat opleveren.
    Skynet ICT B.V. - The cause of the problem is: the printer thinks its a router.



  3. #3
    Ceph - disk keuze
    geregistreerd gebruiker
    1.086 Berichten
    Ingeschreven
    30/04/09

    Locatie
    NL

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


    KvK nummer: 51985977

    Thread Starter
    Citaat Oorspronkelijk geplaatst door CharlieRoot Bekijk Berichten
    Hoeveel disken heb je en in het nieuwe scenario hoeveel disken krijg je. De snelheid van de disks alleen bepaald de snelheid niet. Ook kun je kijken naar SSD write cache. Het journal doet in elk geval aan IO niets dus dat scheiden zal amper wat opleveren.
    Pardon? Journal doet niks aan IO? Juist wel. Lees even https://www.sebastien-han.fr/blog/20...terns-the-bad/ en https://www.hastexo.com/resources/hi...-osd-journals/.

    More specifically, in order for an OSD to acknowledge a write as completed, the new object must have been written to the OSD's journal. OSDs use a write-ahead mode for local operations: a write hits the journal first, and from there is then being copied into the backing filestore. (Note: if your filestore is using btrfs, the journal is applied in parallel with the filestore write instead. Btrfs still being experimental, however, this is not a configuration often used in production.) Thus, for best cluster performance it is crucial that the journal is fast, whereas the filestore can be comparatively slow.
    Cluster bestaat uit 4 OSD nodes met ieder 5x 1TB SSD.
    Bedoeling is om iedere node uit te breiden met 4 nieuwe disken, met een eigen - los van de SSD - pool. Daarom heeft de huidige aantal disken geen invloed op de performance.
    Laatst gewijzigd door xaban; 02/10/17 om 05:04.

Labels voor dit Bericht

Webhostingtalk.nl

Contact

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