Planet Ceph

Aggregated news from external sources

  • December 5, 2013
    Ceph + OpenStack :: Part-1

    Ceph & OpenStack IntegrationWe can use Ceph Block Device with openstack through libvirt, which configures the QEMU interface tolibrbd. To use Ceph Block Devices with openstack , we must install QEMU, libvirt, and&…

  • December 5, 2013
    Ceph Installation :: Part-3

    Creating Block Device from CephFrom monitor node , use ceph-deploy to install Ceph on your ceph-client1 node.[root@ceph-mon1 ~]# ceph-deploy install ceph-client1[ceph_deploy.cli][INFO ] Invoked (1.3): /usr/bin/ceph-deploy install ceph-client1[ceph_dep…

  • December 5, 2013
    Ceph Installation :: Part-2

    CEPH Storage ClusterInstalling Ceph Deploy ( ceph-mon1 )Update your repository and install ceph-deploy on ceph-mon1 node[ceph@ceph-mon1 ~]$ sudo yum update && sudo yum install ceph-deployLoaded plugins: downloadonly, fastestmirror, securityLoad…

  • December 5, 2013
    Ceph Installation :: Part-1
    Ceph Installation Step by Step

    This quick start setup helps to deploy ceph with 3 Monitors and 2 OSD nodes with 4 OSD each node. In this we are using commodity hardware running CentOS 6.4

    Ceph-mon1 : First Monitor + Ceph-deploy machine (will be used to deploy ceph to other nodes )

    Ceph-mon2 : Second Monitor ( for monitor quorum )

    Ceph-mon3 : Third Monitor ( for monitor quorum )

    Ceph-node1 : OSD node 1 with 10G X 1 for OS , 440G X 4 for 4 OSD

    Ceph-node2 : OSD node 2 with 10G X 1 for OS , 440G X 4 for 4 OSD

    Ceph-Deploy Version is 1.3.2 , Ceph Version 0.67.4 ( Dumpling )

    Preflight Checklist 

    All the Ceph Nodes may require some basic configuration work prior to deploying a Ceph Storage Cluster.

    CEPH node setup

    • Create a user on each Ceph Node.
    sudo useradd -d /home/ceph -m ceph
    sudo passwd ceph
    • Add root privileges for the user on each Ceph Node.
    echo "ceph ALL = (root) NOPASSWD:ALL" | sudo tee /etc/sudoers
    sudo chmod 0440 /etc/sudoers
    • Configure your ceph-deploy node ( ceph-mon1) with password-less SSH access to each Ceph Node. Leave the passphrase empty , repeat this step for CEPH and ROOT users.
    ceph@ceph-admin:~ [ceph@ceph-admin ~]$ ssh-keygen
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/ceph/.ssh/id_rsa): yes
    Created directory '/home/ceph/.ssh'.
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /home/ceph/.ssh/id_rsa.
    Your public key has been saved in /home/ceph/.ssh/
    The key fingerprint is:
    The key's randomart image is:
    +--[ RSA 2048]----+
    | |
    | E. o |
    | .. oo . |
    | . .+..o |
    | . .o.S. |
    | . + |
    | . o. o |
    | ++ .. . |
    | ..+*+++ |

    • Copy the key to each Ceph Node. ( Repeat this step for ceph and root users )
    [ceph@ceph-mon1 ~]$ ssh-copy-id ceph@ceph-node2
    The authenticity of host 'ceph-node2 (' can't be established.
    RSA key fingerprint is ac:31:6f:e7:bb:ed:f1:18:9e:6e:42:cc:48:74:8e:7b.
    Are you sure you want to continue connecting (yes/no)? y
    Please type 'yes' or 'no': yes
    Warning: Permanently added 'ceph-node2,' (RSA) to the list of known hosts.
    ceph@ceph-node2's password:
    Now try logging into the machine, with "ssh 'ceph@ceph-node2'", and check in: .ssh/authorized_keys
    to make sure we haven't added extra keys that you weren't expecting.
    [ceph@ceph-mon1 ~]$
    • Ensure connectivity using ping with hostnames , for convenience we have used local host file , update host file of every node with details of other nodes. PS : Use of DNS is recommended
    • Packages are cryptographically signed with the release.asc key. Add release key to your system’s list of trusted keys to avoid a security warning:
    sudo rpm --import ';a=blob_plain;f=keys/release.asc'
    • Ceph may require additional additional third party libraries. To add the EPEL repository, execute the following:
    su -c 'rpm -Uvh'
    sudo yum install snappy leveldb gdisk python-argparse gperftools-libs
    • Installing Release packages , Dumpling is the most recent stable release of Ceph. ( by the time i am creating this wiki )
    su -c 'rpm -Uvh'
    • Adding ceph to YUM , create repository file for ceph /etc/yum.repos.d/ceph.repo
    name=Ceph packages for $basearch

    name=Ceph noarch packages

    name=Ceph source packages
    • For best results, create directories on your nodes for maintaining the configuration generated by ceph . These should get auto created by ceph however in may case it gave me problems. So creating manually.
    mkdir -p /etc/ceph /var/lib/ceph/{tmp,mon,mds,bootstrap-osd} /var/log/ceph
    • By default, daemons bind to ports within the 6800:7100 range. You may configure this range at your discretion. Before configuring your IP tables, check the default iptables configuration. ::ports within the 6800:7100 range. You may configure this range at your discretion. Since we are performing test deployment we can disable iptables on ceph nodes . For moving to production this need to be attended.

    Please Follow Ceph Installation :: Part-2 for next step in installation

  • December 5, 2013
    Ceph Storage :: Introduction

    What is CEPH

    Ceph is an open-source, massively scalable, software-defined storage system which provides object, block and file system storage from a single clustered platform. Ceph’s main goals is to be completely distributed without a single point of failure, scalable to the exabyte level, and freely-available. The data is replicated, making it fault tolerant. Ceph software runs on commodity hardware. The system is designed to be both self-healing and self-managing and self awesome 🙂

    CEPH Internals

    • OSD: A Object Storage Daemon (OSD) stores data, handles data replication, recovery, backfilling, rebalancing, and provides some monitoring information to Ceph Monitors by checking other Ceph OSD Daemons for a heartbeat. A Ceph Storage Cluster requires at least two Ceph OSD Daemons to achieve an active + clean state when the cluster makes two copies of your data . 
    • Monitor: A Ceph Monitor maintains maps of the cluster state, including the monitor map, the OSD map, the Placement Group (PG) map, and the CRUSH map. Ceph maintains a history (called an “epoch”) of each state change in the Monitors, Ceph OSD Daemons, and PGs.
    • MDS: A Ceph Metadata Server (MDS) stores metadata on behalf of the Ceph Filesystem . Ceph Metadata Servers make it feasible for POSIX file system users to execute basic commands like ls, find, etc. without placing an enormous burden on the Ceph Storage Cluster.
    Note :: Please use and other official InkTank and ceph community resources as a primary source of information on ceph . This entire blog is an attempt help beginners in setting up ceph cluster and sharing my troubleshooting with you.

  • December 2, 2013
    Ceph and Swift: Why we are not fighting.

    I have just come back from the OpenStack summit in Hong Kong. As always it was a blast talking to lot of people and listening to presentations or designing the future of the software we all love. While chatting with different people there was a recurrent question coming up to me: people wanted to know whether “Ceph is better than… Read more →

  • November 26, 2013

    Thanks to the hard work of the puppet-openstack
    community, Puppet was the preferred method of deployment for Openstack
    in the latest Openstack User Survey.

    If you’d like to join in on the fun and contribute, read on !
    First things first, a bit of context:

    • Openstack is a modular cloud orchestration platform,
      self-described as “Open source software for building private and
      public clouds”.
    • puppet-openstack is a Stackforge project that centralizes the
      development of puppet modules related to Openstack. puppet-openstack
      is also an actual module allowing the installation and
      configuration of core Openstack services.
    • Stackforge is used to host Openstack-related projects so that they
      can benefit from the same continuous integration infrastructure and
      review system that the main Openstack projects use such as Nova.

    Now that we have the basics out of the way, if you’d like to contribute
    to Openstack in general, it’s not mandatory to have any programming or
    networking knowledge. There’s always things like documentation and
    translation that need manpower.

    For contributing to puppet-openstack in particular, however, it is
    required to be (or become!) familiar with ruby, puppet,
    puppet-rspec and of course, Openstack..

    The contribution process for puppet-openstack is slightly different than
    committing code to primary Openstack projects (such as Nova) and I won’t
    be highlighting them here for the sake of simplicity – this is a topic
    for another blog post !

    I recently started contributing as part of the
    new puppet-ceph initiative so this blog post more or less describes
    what I had to go through to get my first contribution in.

    Okay, sign me up.

    If you want to join in on the fun, the basic instructions for signing up
    are pretty well documented on the Openstack

    In a nutshell:

    Getting started

    Let’s say I want to develop for puppet-ceph (!), I’ll keep these
    resources handy:

    • The Launchpad project for bugs/issues/fixes/feature/backlog
      documentation and
      discussion: (each project
      has it’s own launchpad project)
    • The developer documentation will prove useful to prepare your
      development environment and beyond. For puppet modules,
      documentation is provided both on the Openstack
      and directly in the README files.

    Clone the project

    You’re going to need the puppet module source to work on it, you can
    either clone it from Github:

    git clone

    or from Gerrit:

    git clone

    Make sure you have ruby, rubygems and bundle installed

    First of all, you’ll need ruby and bundle to manage ruby
    packages (gems).
    These will be required, especially when the time will come to do
    spec/integration/lint tests.

    If you already have them you can skip this part !

    On Ubuntu:

    apt-get install ruby rubygems ruby-bundler

    On Debian:

    apt-get install ruby rubygems bundler

    Install development dependencies

    With the help of bundle, fetch and install the gem dependencies
    documented in the Gemfile located at the root of the repository.

    bundle install

    Create your branch and do your stuff

    Create a branch with a name relevant to what you’re doing

    git checkout -b feature/my_feature

    Now you can do your modifications.
    Don’t forget to add new spec tests or modify existing ones to match the
    modifications you made to the module.

    Test your stuff

    You’ve added or modified some code, now you want to test it:

    Test for puppet syntax (puppet-lint):

    bundle exec rake lint

    Run spec tests (puppet-rspec)

    bundle exec rake spec

    If you try to push code that doesn’t pass the tests, jenkins will not
    let you through – better make sure everything is okay before sending
    something for review!

    Tests are successful ? Add and commit your stuff

    git add [file] git commit

    Make sure your commit message follows the right format !

    Send your stuff for review

    git review

    That’s it ! Your code was sent to gerrit for review by the community
    and the core reviewers !

    Jenkins or someone -1’d my code. Help !

    Maybe you did a typo or something far worse you’d like to fix – this is
    done by submitting another patch set.

    Do the changes you want to do, add the files again but instead of using
    git commit‘, use ‘git commit —amend‘.
    This will essentially modify the initial commit.

    After amending your commit, send the code back for a new review with
    git review‘ once more.

  • November 26, 2013
    Back from the summit: Ceph/OpenStack integration

    The summit was exciting and full of good things and announcements. We had great Cinder sessions and an amazing Ceph/OpenStack integration session. I’ve led the Ceph/OpenStack integration session with Josh Durgin (Inktank). We had a good participation from the audience. I would like to specially thank Sage Weil, Haomai Wang, Edward Hope-Morley for their good inputs. The main purpose of… Read more →

  • November 21, 2013
    Manage a multi-datacenter crush map with the command line

    A new datacenter is added to the crush map of a Ceph cluster: # ceph osd crush add-bucket fsf datacenter added bucket fsf type datacenter to crush map # ceph osd crush move fsf root=default moved item id -13 name … Continue reading

  • November 19, 2013
    Mixing Ceph and LVM volumes in OpenStack

    Ceph pools are defined to collocate volumes and instances in OpenStack Havana. For volumes that do not need the resilience provided by Ceph, a LVM cinder backend is defined in /etc/cinder/cinder.conf: [lvm] volume_group=cinder-volumes volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver volume_backend_name=LVM and appended to the list … Continue reading

  • November 18, 2013
    Creating a Ceph OSD from a designated disk partition

    When a new Ceph OSD is setup with ceph-disk on a designated disk partition ( say /dev/sdc3 ), it will not be prepared and the sgdisk command must be run manually: # osd_uuid=$(uuidgen) # partition_number=3 # ptype_tobe=89c57f98-2fe5-4dc0-89c1-f3ad0ceff2be # sgdisk –change-name=”${partition_number}:ceph … Continue reading

  • November 16, 2013
    Display the default Ceph configuration

    The ceph-conf command line queries the /etc/ceph/ceph.conf file. # ceph-conf –lookup fsid 571bb920-6d85-44d7-9eca-1bc114d1cd75 The –show-config option can be used to display the config of a running daemon: ceph -n osd.123 –show-config When no name is specified, it will show the … Continue reading