Private corporate batches, live online cohorts and 1-on-1 mentoring in replicated block storage, snapshots, backups and disaster recovery for Kubernetes — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Longhorn from the data path outward — manager, engine and replica processes, what a synchronous write actually does, and what degraded means — before any StorageClass is written. The syllabus then covers the operational half most teams skip: snapshot chains and space reclamation, backup targets and verified restores, disaster-recovery volumes across clusters, and live upgrade of manager and engine images. Sessions run against a real multi-node cluster and include deliberately killing nodes mid-write, because rebuild behaviour is the only honest test of a storage system.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Longhorn that means a trainer who has run it in production — replicated block storage, snapshots, backups and disaster recovery for Kubernetes — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Longhorn batchLonghorn is a CNCF distributed block storage system for Kubernetes, originally built at Rancher. It turns the local disks already attached to your nodes into replicated persistent volumes, exposed through a standard CSI driver, so a StatefulSet gets a PersistentVolumeClaim that survives the loss of the node it was scheduled on.
Its design choice is microservices rather than a monolithic storage cluster. A longhorn-manager DaemonSet runs on every node; each volume gets its own dedicated engine process acting as the controller, and each replica is a separate process on a different node writing to a sparse file under the node's disk. Writes are replicated synchronously to every replica, and because each volume has its own engine, a problem with one volume does not degrade the rest of the cluster. That is a very different failure model from a shared distributed filesystem, and it is why Longhorn is comparatively easy to reason about.
Around that core sits the operational machinery that matters in production: crash-consistent snapshots stored on the volume itself, incremental backups to S3-compatible object storage or NFS, RecurringJob resources to schedule snapshots, backups and filesystem trim, disaster-recovery volumes that continuously restore from a backup target in a second cluster, ReadWriteMany volumes through a share-manager, volume expansion, encrypted volumes, and per-StorageClass control over replica count, data locality and node and disk selection.
Stateful workloads moved onto Kubernetes and the storage question stopped being optional. Databases, message brokers, artifact stores, CI caches and monitoring backends all need persistent volumes, and the answer is no longer obviously the cloud provider's block service — a growing share of clusters run on bare metal, in a colocation facility, at an edge site or on a virtualisation platform where no EBS equivalent exists.
Longhorn fills that gap without asking a platform team to become Ceph operators. It installs as a Helm chart, uses the disks already present, and presents a UI and a CSI driver. That accessibility is genuine, and it is also the trap: teams adopt it in an afternoon, run it with default settings, and meet the consequences during their first node failure or their first attempt to restore.
The skills that matter are the unglamorous ones. Sizing replicas and understanding what a degraded volume actually means. Knowing when data locality helps and when it silently reduces resilience. Configuring a backup target and then proving a restore works, in a different cluster, before you need it. Planning capacity when snapshots consume space on the same disks. Upgrading the manager and the per-volume engines without taking workloads down. Those are what this training is about.
The storage landscape before the tool. How PV, PVC, StorageClass and CSI actually fit together, the difference between replicated block, shared filesystem and object storage, and an honest comparison of Longhorn against cloud block services, Rook-Ceph, NFS and local volumes.
Topics: PersistentVolume, PersistentVolumeClaim, StorageClass and the binding process · The CSI architecture: controller and node plugins, attach, mount, expand · Access modes: ReadWriteOnce, ReadWriteMany, ReadWriteOncePod · Replicated block vs shared filesystem vs object storage · Longhorn vs cloud EBS-class services vs Rook-Ceph vs NFS · Workload profiles that suit Longhorn and ones that do not · Hardware expectations: disks, network and node count
The internals, because every later troubleshooting session depends on them. The longhorn-manager DaemonSet, the per-volume engine as controller, replica processes and their sparse files, the instance manager, and exactly what happens on a write and on a read.
Topics: longhorn-manager DaemonSet and the CRD set · Per-volume engine as controller, and why one engine per volume · Replica processes, sparse files and the node disk layout · Instance manager pods and their lifecycle · Synchronous replication: the write path in detail · The read path and where data locality changes it · CSI plugin components: attacher, provisioner, resizer, snapshotter · Longhorn UI and what it exposes
Getting the foundation right, since most Longhorn problems trace back to it. Node prerequisites that are easy to miss, installing via Helm, adding and tagging disks, scheduling constraints, and the global settings worth changing before any workload arrives.
Topics: Node prerequisites: open-iscsi, nfs-common, kernel modules and mount propagation · Installation with Helm and the longhorn-system namespace · The environment check script and reading its output · Adding disks, mount points and storage reservation · Node and disk tags for scheduling control · Scheduling settings: over-provisioning, minimal available percentage, replica soft and hard anti-affinity · Default settings worth changing on day one · Uninstall behaviour and data safety
Turning the installation into storage a workload can use. Every StorageClass parameter that matters and what it costs, data locality and its resilience trade-off, online expansion, ReadWriteMany through the share-manager, and encrypted volumes.
Topics: StorageClass parameters: numberOfReplicas, staleReplicaTimeout, fsType, reclaim policy · dataLocality: disabled, best-effort and strict-local, and the trade-off · diskSelector, nodeSelector and tag-based placement · replicaAutoBalance and rebalancing behaviour · Volume expansion online and offline · ReadWriteMany volumes via the share-manager · Encrypted volumes with CSI secrets · Attaching, detaching and multi-attach errors
The half of Longhorn that only proves itself when something has gone wrong. Snapshot chains and what they cost in space, configuring a backup target, incremental backup mechanics, scheduling with RecurringJobs, and disaster-recovery volumes that stay warm in a second cluster.
Topics: Snapshots: crash consistency, the snapshot chain and space cost · Application-consistent snapshots and quiescing a database · Backup targets: S3-compatible object storage and NFS · Incremental backup mechanics and the backupstore layout · RecurringJob resources for snapshot, backup and trim · Restoring a volume in place and into a new PVC · Disaster-recovery volumes and cross-cluster activation · Retention, expiry and cleaning up orphaned backups
What actually happens when hardware misbehaves. Node and disk failure, degraded volumes and rebuild behaviour, replica anti-affinity, the eviction and node-drain policies, then performance: what synchronous replication costs, where the bottleneck usually is, and how to measure it honestly.
Topics: Node failure: detach, reattach and replica rebuild · Degraded volumes, staleReplicaTimeout and rebuild throughput · Disk failure and replica eviction · Replica anti-affinity, zone awareness and failure domains · Node drain policy and maintenance without data loss · Performance characteristics of synchronous replication · Network as the usual bottleneck, and separating storage traffic · Benchmarking with realistic workloads rather than synthetic peaks · Filesystem trim and reclaiming space
Running Longhorn for years rather than weeks. Upgrading the manager and then the per-volume engines without downtime, Prometheus metrics and the alerts worth having, capacity planning that accounts for replicas and snapshots, and a structured troubleshooting order.
Topics: Upgrading longhorn-manager via Helm and the version support window · Live engine image upgrade per volume · Prometheus metrics and Grafana dashboards for Longhorn · Alerts that matter: degraded volumes, disk pressure, backup failure · Capacity planning with replica factor, snapshots and over-provisioning · Backing images and the V2 data engine: what they are and when to consider them · Structured troubleshooting: workload, CSI, engine, replica, disk · Support bundles and what to collect before asking for help
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstall Longhorn across a multi-node cluster, add and tag a second disk on two nodes, and fix every prerequisite the environment check flags.
Write StorageClasses for a database, a cache and a shared media store, defending replica count, data locality and selectors for each.
Destroy a node while a workload writes continuously, then track detach, reattach, degraded state and rebuild to completion with the data verified.
Configure an S3-compatible backup target, schedule RecurringJobs, then restore the volume into a second cluster and start the application against it.
Stand up a DR volume continuously restoring in a second cluster, then activate it and measure the actual recovery time.
Upgrade manager and engine images live, wire Prometheus alerts for degraded volumes and backup failure, then run a mixed failure drill and write the runbook.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.