..........................................................................................................................................................................
Problem: It is important to use common terminology while administering a solution, and its even more important to know what each service or terminology used in solution actually does in meeting what is expected of the solution. It helps connect the dots.
What are System Internals of Cohesity and what each Internal
Service function is responsible for?
Magneto Service:
Magneto service is the heart of Cohesity solution, which is responsible
for Cohesity Integrated Backup Software i.e. DataProtect. Magneto is a backup
Engine that integrates Backup service with VMWare vCenter VADP), Oracle, SQL
Server, Pure Storage, Netapp, and more.
IRIS Service:
This service provides user interface to interact with
Cohesity resources by allowing access to cluster and its services. This
facilitates the REST API orchestration. This service is responsible for Web GUI
for system management and CLI for advanced Commands.
Gandalf Service:
This is a Cluster Health and State Manager Service. Holds
Distributed lock manager and holds Binary Configuration for other processes.
Nexus Service:
This manages platform level operations, while also
starts/stops OS level services. Common tasks this performs includes node
discovery, cluster initialization, VIP management, and IP/DNS/NTP
configuration. This service also manages NON-Disruptive-Upgrades (NDU).
Scribe Service:
This service is responsible for Distributed metadata and
journaling. It uses Paxos algorithm for data consistency while holds the metadata
for the file systems such as files, snapshots, segments, dedupe chunks, data
location and such.
Bridge Service:
This is a main Engine Controller for I/O Operations. This
exposes FS types (VIEW- SMB, NFS, and S3) to Clients. This is responsible for
updating Scribe of data location, chunking bite streams, and sending to the blob
store.
What is Blob?
Blob is a system object that is simply logical allocation of
bricks. Bricks is an entity that can be part of which that makes up small files
(<=8MB). Whereas, MegaFile(256GB+) is multiple blobs from different nodes.
Therefore, here is how the hierarchy would look like:-- Inodes are smallest
entity within an inode snaptree that defines file system objects, and
hierarchy. Inodes point to Blobs. Blobs are part of bigger entity i.e. Bricks.
Hydra Service:
This is a front-end write cache for bridge. Once data gets
written on Cohesity, it is written in native format in Hydra level, where read
can be performed directly from hydra if needed. It then flushes to blob store
on SSD and HDD depending on I/O profile.
Yoda Service:
Yoda is an Indexing engine, is responsible for indexing
files within VM and/or other backed up object based on policy defined if to
enable indexing or not. Once Backup job is completed, that’s when Yoda service
kicks in.
Genie Service:
This is essentially a service to enable remote tunnel for
support. This service checks some other monitoring features such as monitoring
hardware hearbeat and health.
Eagle Service:
This service enable data reporting to support (call-home)
and support for dark site collection/upload/analysis. It also analyses support
data for install base, support and analytics in terms of statistics and alerts.
This further sensors that monitor hardware and software.
Note: All the information I have used here is a
cumulative information gathering from working knowledge with Field Engineers, Account
System Engineers, Cohesity Documentation from support site, as well as personal
understanding which I have gathered by conversation with Support tech, and hands on experience. I have
tried my best to best reflect accuracy. This is Strictly for the audience who
are new and/or current Cohesity users.
You Are Welcome
