← Back to Course Index

Week 10 Lab: Persistent Cloud Storage

Module: Operating Systems 3 (Virtualisation & Cloud Technologies)

Estimated Time: 60 Minutes
Lab Type: Practical / CLI & GUI

Lab Overview

By the end of this lab, you will understand Data Persistence in the cloud. You will simulate a common cloud scenario: A server failure where the data must survive.

Objectives:

1. Create a Cinder Block Volume.
2. Attach it to an instance.
3. Format and Mount it in Linux.
4. Simulate Migration: Detach it and move it to another server, proving the data survives.
5. Secure it: Create a custom Web Server Security Group.

Prerequisites:

• MicroStack installed.
• Two running instances (Launch vm-A and vm-B if you don't have them).
• Floating IP available.

Part 1: The Volume Lifecycle

1. Create Volume:

   • GUI: Project > Volumes > Volumes > Create Volume.
   • Name: data-vol-1.
   • Size: 1 GiB.
   • Type: __DEFAULT__ (or iSCSI/LVM).
   • Click Create Volume.

2. Attach Volume:

   • Locate data-vol-1 in the list.
   • Click the arrow > Manage Attachments.
   • Attach to Instance: Select vm-A.
   • Click Attach Volume.
   • Result: Status changes to "In-use".

3. Field Report:

   • Volume Status: [ _____________________________ ]
   • Attached to: [ _____________________________ ]

Part 2: Linux Configuration (Inside VM-A)

1. SSH into VM-A.

2. Identify the Disk: bash lsblk

   • You should see vda (Boot disk, ~5-10GB) and vdb (Your 1GB volume).
   • Note: If you chose a different flavor or hypervisor, it might be sdb or vdc.
   • Format: WARNING: Ensure you target /dev/vdb. bash sudo mkfs.ext4 /dev/vdb
   • Mount: bash sudo mkdir /cinder-data sudo mount /dev/vdb /cinder-data
   • Write Data: bash sudo sh -c 'echo "This data must survive!" > /cinder-data/secret.txt' cat /cinder-data/secret.txt

Part 3: The Migration Test (Simulated Failure)

VM-A is about to be deleted. We must save the data.

1. Unmount (Crucial!): You cannot detach a mounted disk safely. bash sudo umount /cinder-data exit

2. Detach:

   • GUI: Volumes > data-vol-1 > Manage Attachments > Detach Volume.
   • Confirm the detachment.

   • Attach to VM-B:

   • GUI: Volumes > data-vol-1 > Manage Attachments > Select vm-B.

   • Verify on VM-B:

   • SSH into vm-B.

   • Mount it (No formatting needed!): bash sudo mkdir /restored-data sudo mount /dev/vdb /restored-data

   • Check for file: bash cat /restored-data/secret.txt

   • Success Condition: You see "This data must survive!".

3. Field Report:

   • Did the file survive? [ Yes / No ]
   • What command verifies the disk size? [ _____________________________ ]

Part 4: Security Group Challenge

1. Create a group: web-sg.

2. Add Rules:

   • Allow TCP 80 (HTTP).
   • Allow TCP 443 (HTTPS).
   • Do NOT allow SSH.

   • Apply to an Instance:

   • Select an instance > Edit Security Groups.

   • Remove default group. Add web-sg.

   • Test:

   • Try to SSH to that instance from your laptop.

   • It should Time Out (Hang).
   • Note: "Connection Refused" means the firewall allowed you, but the service is down. "Time Out" means the firewall dropped the packet.

3. Critical Thinking:

   • Why is "Time Out" better than "Connection Refused" against hackers?
   • [ _________________________________________________________________________ ]

Lab Checkpoint

• I have created, formatted, and mounted a Cinder Volume.
• I have successfully migrated the Volume to a second VM without data loss.
• I have created a custom Security Group and verified it blocks SSH.

Reflection:

• In Part 3, why didn't we need to run mkfs.ext4 again on VM-B?
• If we used "Instance Storage" (Ephemeral) instead of Cinder, what would have happened to the file?

Instructor Signature: ___ Date: ___

← Back to Course Index