Build and validate a scale-out Samba/CTDB cluster atop CephFS
an invention by dmdiss
Updated over 5 years ago. 1 hackers ♥️.

Samba and CTDB rely heavily on POSIX fcntl locks for data and meta-data integrity. This functionality was recently fixed in CephFS, opening up the possibility to use CephFS as an underlying filesystem for a scale-out Samba/CTDB cluster.

Such an architecture should perform and scale much better than the existing single Samba + VFS module gateway.

Looking for hackers with the skills:

smb samba ctdb cluster ha ceph

This project is part of:

Hack Week 10

Activity

  • about 11 years ago: dmdiss started this project.
  • about 11 years ago: gnyers liked this project.
  • about 11 years ago: dmdiss added keyword "smb" to this project.
  • about 11 years ago: dmdiss added keyword "samba" to this project.
  • about 11 years ago: dmdiss added keyword "ctdb" to this project.
  • about 11 years ago: dmdiss added keyword "cluster" to this project.
  • about 11 years ago: dmdiss added keyword "ha" to this project.
  • about 11 years ago: dmdiss added keyword "ceph" to this project.
  • about 11 years ago: dmdiss originated this project.


    • Comments

    • dmdiss
      about 11 years ago by dmdiss | Reply

      I large chunk of my Hack Week time packaging ceph, ceph-deploy and associated build / runtime requirements. The packages can be found on the build service at: home:dmdiss:ceph -> merged to filesystems devel package home:dmdiss:ceph-deploy -> merged to filesystems devel package home:dmdiss:ceph_lts LevelDB was submitted as a new factory devel package.

      The devel packages still need to be submitted to Factory, for inclusion in openSUSE 13.2.

    Similar Projects

    Modularization and Modernization of cifs.ko for Enhanced SMB Protocol Support by hcarvalho

    Creator:
    Enzo Matsumiya ematsumiya@suse.de @ SUSE Samba team
    Members:
    Henrique Carvalho henrique.carvalho@suse.com @ SUSE Samba team

    Description

    Split cifs.ko in 2 separate modules; one for SMB 1.0 and 2.0.x, and another for SMB 2.1, 3.0, and 3.1.1.

    Goals

    Primary

    Start phasing out/deprecation of older SMB versions

    Secondary

    • Clean up of the code (with focus on the newer versions)
    • Update cifs-utils
    • Update documentation
    • Improve backport workflow (see below)

    Technical details

    Ideas for the implementation.

    • fs/smb/client/{old,new}.c to generate the respective modules
      • Maybe don't create separate folders? (re-evaluate as things progresses!)
    • Remove server->{ops,vals} if possible
    • Clean up fs_context.* -- merge duplicate options into one, handle them in userspace utils
    • Reduce code in smb2pdu.c -- tons of functions with very similar init/setup -> send/recv -> handle/free flow
    • Restructure multichannel
      • Treat initial connection as "channel 0" regardless of multichannel enabled/negotiated status, proceed with extra channels accordingly
      • Extra channel just point to "channel 0" as the primary server, no need to allocate an extra TCPServerInfo for each one
    • Authentication mechanisms
      • Modernize algorithms (references: himmelblau, IAKERB/Local KDC, SCRAM, oauth2 (Azure), etc.

    Modularization and Modernization of cifs.ko for Enhanced SMB Protocol Support by hcarvalho

    Creator:
    Enzo Matsumiya ematsumiya@suse.de @ SUSE Samba team
    Members:
    Henrique Carvalho henrique.carvalho@suse.com @ SUSE Samba team

    Description

    Split cifs.ko in 2 separate modules; one for SMB 1.0 and 2.0.x, and another for SMB 2.1, 3.0, and 3.1.1.

    Goals

    Primary

    Start phasing out/deprecation of older SMB versions

    Secondary

    • Clean up of the code (with focus on the newer versions)
    • Update cifs-utils
    • Update documentation
    • Improve backport workflow (see below)

    Technical details

    Ideas for the implementation.

    • fs/smb/client/{old,new}.c to generate the respective modules
      • Maybe don't create separate folders? (re-evaluate as things progresses!)
    • Remove server->{ops,vals} if possible
    • Clean up fs_context.* -- merge duplicate options into one, handle them in userspace utils
    • Reduce code in smb2pdu.c -- tons of functions with very similar init/setup -> send/recv -> handle/free flow
    • Restructure multichannel
      • Treat initial connection as "channel 0" regardless of multichannel enabled/negotiated status, proceed with extra channels accordingly
      • Extra channel just point to "channel 0" as the primary server, no need to allocate an extra TCPServerInfo for each one
    • Authentication mechanisms
      • Modernize algorithms (references: himmelblau, IAKERB/Local KDC, SCRAM, oauth2 (Azure), etc.

    SMB3 Server written entirely in Rust by dmulder

    Description

    Given the number of bugs frequently discovered in the Samba code caused by memory issues, it makes sense to re-write the smbd service purely in Rust code. Meanwhile, it would be wise to abandon backwards compatibility here with insecure protocol versions, and simply implement the SMB3 spec.

    Goals

    Get a simple server up and running and get it merged into upstream Samba (which now has Rust build support).

    Resources

    Expand the pacemaker/corosync3 cluster toward 100+ nodes by zzhou

    Description

    Along with pacemaker3 / corosync3 stack landed openSUSE Tumbleweed. The new underline protocol kronosnet becomes as the fundamental piece.

    This exercise tries to expand the pacemaker3 cluster toward 100+ nodes and find the limitation and the best practices to do so.

    Resources

    crmsh.git/test/run-functional-tests -h