Debugging A Live Gluster File System

Meta is a client side xlator which provide an interface similar to the Linux procfs, for GlusterFS runtime and configuration. The contents are provided using a virtual hidden directory called .meta which is inside the root of GlusterFS mount..meta is an efficient way to extract information from a live running mount process with out using gdb , systemtap or any such tools. This doesn't require any prior knowledge about any tools, the information's are given as directory / file tree structure. So for a users this is the most simplest way to start looking to complicated problems and developers can get information with out disturbing the cluster.
I will be covering the following topics * What is .meta layer and current state of meta layer, * Information's that can be fetched through .meta directory * Debugging with .meta directory (for both developers and users) * How to debug graph related issues * latency and mallinfo * Fop history and fuse history using meta * Current running frames or pending frames * Enhancement planned for meta layer * Other troubleshooting options like statedump,io-stat, etc

The name Gluster combined GNU and cluster. Despite the similarity in names, Gluster is not related to the Lustre file system and does not incorporate any Lustre code. Gluster based its product on GlusterFS, an open-source software-based network-attached filesystem that deploys on commodity hardware.The initial version of GlusterFS was written by Anand Babu Periasamy, Gluster's founder and CTO.In May 2010 Ben Golub became the president and chief executive officer.
Red Hat became the primary author and maintainer of the GlusterFS open-source project after acquiring the Gluster company in October 2011.The product was first marketed as Red Hat Storage Server, but in early 2015 renamed to be Red Hat Gluster Storage since Red Hat has also acquired the Ceph file system technology.
The GlusterFS architecture aggregates compute, storage, and I/O resources into a global namespace. Each server plus attached commodity storage (configured as direct-attached storage, JBOD, or using a storage area network) is considered to be a node. Capacity is scaled by adding additional nodes or adding additional storage to each node. Performance is increased by deploying storage among more nodes. High availability is achieved by replicating data n-way between nodes.
Public cloud deploymentFor public cloud deployments, GlusterFS offers an Amazon Web Services (AWS) Amazon Machine Image (AMI), which is deployed on Elastic Compute Cloud (EC2) instances rather than physical servers and the underlying storage is Amazon's Elastic Block Storage (EBS).In this environment, capacity is scaled by deploying more EBS storage units, performance is scaled by deploying more EC2 instances, and availability is scaled by n-way replication between AWS availability zones.
Private cloud deployment
A typical on-premises, or private cloud deployment will consist of GlusterFS installed as a virtual appliance on top of multiple commodity servers running hypervisors such as KVM, Xen, or VMware; or on bare metal.
GlusterFS is a scale-out network-attached storage file system. It has found applications including cloud computing, streaming media services, and content delivery networks. GlusterFS was developed originally by Gluster, Inc. and then by Red Hat, Inc., as a result of Red Hat acquiring Gluster in 2011.
In June 2012, Red Hat Storage Server was announced as a commercially supported integration of GlusterFS with Red Hat Enterprise Linux.Red Hat bought Inktank Storage in April 2014, which is the company behind the Ceph distributed file system, and re-branded GlusterFS-based Red Hat Storage Server to "Red Hat Gluster Storage".

Original video is from https://fosdem.org
This work is licensed under the Creative Commons Attribution 2.0 Belgium Licence.
To view a copy of this licence, visit http://creativecommons.org/licenses/by/2.0/be/deed.en
or send a letter to Creative Commons, 444 Castro Street, Suite 900, Mountain View, California, 94041, USA.