virtual Storage Area Network (vSAN)

Sebuah komponen yang tidak terpisah dari Hyper-Converged Infrastructure (HCI) dan sebagai salah satu bentuk implementasi Software Defined Storage (SDS). Menggabungkan secara logic media-media penyimpanan fisik pada tiap-tiap resource server menjadi satu clustered datastore

vSAN memungkinkan untuk tersedianya storage media yang berkapasitas sangat besar, cocok untuk implementasi di organisasi yang volume-concerned repository. Dilain sisi, media-media yang sudah tergabung dalam clustered datastore yang sudah dibuat, membutuhkan acknowledgement bahwa dirinya masih tergabung dalam clustered datastore tersebut, dan masih managed by vCenter yang sama dan konsisten. Oleh karenanya, read & write frequency, IOPS, rates, dan bandwidth juga akan menjadi konsisten, yang pada akhirnya berpotensi mengurangi life-time perangkat, dalam kondisi operasional extrem dan konsisten.

Hyper-converged Infrastructure (HCI)

Hyper-converged Infrastructure (HCI), adalah sebuah konsep SDDC proprietary VMWare dimana didalamnya terdapat komponen-komponen; computing, data networking, dan storage yang keseluruhannya diatur dalam satu management vCenter yang sama.

Compute sebagai komponen utama, mengatur pembagian resources fisik untuk dapat menjalankan proses-proses yang dibutuhkan oleh para virtual server yang ada didalamnya. Selanjutnya, para virtual server tersebut untuk memunkinkan operasionalnya membutuhkan pengaturan yang dilakukan oleh komponen Network sebagai penghubung komunikasi data antar virtual server dan jaringan data dunia nyata.

Komponen Storage merupakan media penyimpanan sentral HCI (repository) yang padanya banyak metode read & write yang dapat diterapkan, salah satunya dengan metode vSAN yang adalah proprietary VMware.

Management, Control, and Data plane

Plane dalam konteks jaringan data, adalah suatu konsep dari gabungan 3 (tiga) buah komponen arsitektur komunikasi data, yaitu; data, control, dan management. Pada gambar diatas, ketiga komponen ini merupakan bagian dari masing-masing komponen SDDC (compute, network, dan storage), itu berarti masing-masing komponen SDDC memiliki data network communication capabilities.

Data plane, komponen yang bertanggung jawab untuk perpindahan data dari satu end-point ke end-point lainnya. Proses perpindahan ini, jika diterjemahkan dalam operasional OSI layer, maka komponen ini bekerja pada layer-1 dan layer-2, karena perpindahan antar end-point berarti berurusan dengan physical interfaces, bits, packet/frame tagging, switching, iSCSI, FCoE, dan lain-lain.

Control plane, komponen selanjutnya yang mengatur bagaimana paket data akan diteruskan oleh data-plane. Pada komponen ini, terdapat (dan diterapkan) fungsi-fungsi routing, access-policies, packet filtering, SAN, NAS, DAS, dan sebagainya, mengambil fungsi layer-3, 4, dan 5 pada OSI layer, yang sedianya juga adalah fungsi utama perangkat dimaksud.

Management plane, komponen intermuka perangkat dengan brain-ware yang memungkinkan pengaturan perangkat sesuai dengan kapasitas fungsionalnya, juga fungsi-fungsi pengawasan dan pemeriksaan/evaluasi. Aplikasi-aplikasi pada layer-7 adalah model-model intermuka yang digunakan, seperti; CLI, SNMP, Telnet, SSH, HTTP, dlsb.

Software-defined Datacenter

Software Defined Datacenter (SDDC), adalah sebuah evolusi datacenter konvensional dimana komponen control-plane dan management-plane tidak lagi berada pada masing-masing perangkat keras, melainkan disatukan dalam sebuah computing controller memanfaatkan (dan mengoptimalkan) virtualized-environment.

Sentralisasi control-plane dan management-plane ini memungkinkan untuk diterapkannya otomasi konfigurasi dan operasional tanpa adanya sentuhan manusia. Disisi investasi lebih optimal, karena tidak lagi prioritas kepada pengadaan perangkat fisik dan service warranty tahunan.

Perangkat computing-controller sebaliknya, dibutuhkan spesifikasi yang mutahir dengan penerapan fitur-fitur warranty seperti: backup, high-availability, resources load-balancing, dll.

Legacy Datacenter

Legacy datacenter atau disebut juga hardware-defined datacenter, adalah sebuah datacenter konvensional dimana komponen proses hingga interkoneksinya berada dalam perangkat keras (chassis) masing-masing.

Dikarenakan setiap komponen berada dalam perangkat keras masing-masing, maka pengembangan terkait dapat dilakukan tertuju hanya perangkat dimaksud saja, dan tidak mempengaruhi keberadaan &/ fungsional perangkat lain.

Dilain sisi, fungsi management perangkat tersedia untuk masing-masing perangkat yang belum terintegrasi dengan perangkat lainnya.

Anywhere Lab

The limitation of time and space are human nature which is aggressively prohibits by developing and implementing multi-dimensional technology for the past decades. This trend also came to my concern when I’m limited to them to refresh my brain and must wait ‘till I reach my physical machine, or when some idea came up suddenly while I’m in the middle of anything I’m doing, I can’t just brought them up to my lab or simply document it. 

This document is for personal use, nothing commercial, nothing academic. If someone finds this journal fits their purposes, -well, good for you then- but, I will not take any responsible nor credits for the usage of what I’m about to write by anyone but me. 

I need an environment for my lab, which can be access anytime, anywhere, not to depend on physical device, and not supposed to be installing some bothersome apps as privilege to it. It should also persistent, durable, and secure system, since it will also be my “jumper” into another dimension. 

So, I’ll be using Kali-2020 as my basic platform, and (still comfy with) my Cisco IOU as my lab environment. All of ‘em will be standing over VMware Hypervisor 6.5. 

Let’s begin.. 

1. Preparing the platform. 

• VMware Hypervisor 6.5. 

Well, some guys already prepared for it, so I don’t need to pull my hair off to do so. 

• Installing Kali-2020. 

Again, some other guys already prepared .ovf file for me, so I just load it up into the VM host. 

2. Preparing & hardening Kali-2020. 

I’ll be using this machine to public area, so I don’t want it to be so easily accessible by anyone but me or my privileged. 

In this stage, I’ll need linux text editor. I use ‘vi’ since it was pre-installed on my kali. 

2.1. Changing ‘hostname’

To do this, change the file named hostname in /etc. 

kali@kali:~$ sudo vi /etc/hostname 

replace ‘kali’ to whatever we want to be named. I chose ‘mchn’.  Save the document, and then reboot the system. 
After booting, it’ll shows like this:  

kali@mchn:~$  

2.2. Add ‘user’ to ‘root’ group. 
create new user named ‘user‘:

kali@mchn:~$ sudo useradd -m user

 -m’ indicates that we’ll create home folder upon user creation. 

2.3. Set password for ‘user’.

kali@mchn:~$ sudo passwd user  

 1st entry chars for passwords, and 2nd entry for password clarification. 

2.4. add ‘user’ to group ‘sudo’.

kali@mchn:~$ usermod -a -G sudo user 

2.5. Add ‘user’ to the default shell typing. 

kali@mchn:~$ sudo chsh -s /bin/bash/user

2.6. Update & upgrade image.

kali@mchn:~$ sudo apt-get update

kali@mchn:~$ sudo apt-get upgrade

kali@mchn:~$ sudo apt-get dist-upgrade

2.7. Change default ssh keys.
I'll be accessing my lab via public ssh, so this part is a must-do, at least to not make it so easily come-in to your machine, by anyone but me and my privileged.
Ssh keys we need to change, located in /etc/ssh

2.7.1. Find local ssh keys.

kali@mchn:~$ ls /etc/ssh/

ssh_host_* 

2.7.2. Relocate current ssh keys.

kali@mchn:~$ mkdir /etc/ssh/oldkeys 

kali@mchn:~$ mv /etc/ssh/ssh_host_* /etc/ssh/oldkeys/

2.7.3. Create new ssh keys.

kali@mchn:~$ dpkg-reconfigure-openssh-server

ignore any warning messages appeared.

2.7.4. Compare ssh keys. (if you want)

kali@mchn:~$ md5sum /etc/ssh/oldkeys/ssh_host_* /etc/ssh/ssh_host_*

the result between those ssh keys, should NOT be same! it means now we indeed have new ssh keys.

2.8. ssh services.
I need to know what services are already running on my kali.

2.8.1. verify local service ports.

kali@mchn:~$ nmap localhost

PORT  STATE  SERVICE

22/tcp  open      ssh

80/tcp  open      http

23/tcp  open      telnet

3389/udp  open     rdp

2.8.2.  enabling ssh service.

Two ways to do this:

ssh.service => ssh service will always be running.

ssh.socket => sssh service in listening state. It will listen and wait for connection, when it happens, system will then start the ssh service. 

Starts the ssh service: 

kali@mchn:~$ sudo systemctl start ssh.socket

 Add the service to system startup:

kali@mchn:~$ sudo systemctl enable ssh.socket

Verify the service status:

kali@mchn:~$ sudo systemctl status ssh.socket 

2.8.3. ssh access via wan.

Service port 22 somehow cannot go thru easily in wan, so I tricked this by using PAT in my gateway.

The logic would be; ".. direct access to my kali using pre-given public-ip with specific customized custom port, which will then translated to my kali's local-ip serviceport 22.."

(If you don't know or don't have the privilege to do this, contact your IT guy..)

3. Preparing the lab environment. 

I’m migrating my lab into Kali, so it’d no need for me to reveal how to build it. But on my second thought, I’ll do it so I’d have in-one-page docs. ;) 

IOU raw-files. 

Retrieve these files and put ‘em into /home/me/Downloads/ 

Files are: 

• Image files.name’d be like i86bi_linux-ipbasek9-ms or something like that.
  Size varies, largest I have, around 40 MB.
  
• License generator. an exe file called ‘iougen’, some licensing agent that locked iou for commercial use. Well that’s what they said when it was still on development.
  
  When extracted, will shows: 
  

  [License]  = <16 char="" random="">   

• App. Caller. => an exe file called ‘wrapper-linux’, some kind of an app-caller in linux. 
• Machine starter.
  an exe file called 'ioustart', it will run the iou image(s) as predefined before.
  scroll-down for explanation on how to predefined it.
• Machine killer.
  another exe file called 'ioustop', it'll kill all iou process.
  no need to preconfigure it, just put it on lab folder and run it.
• Topology map.
  a text file called NETMAP, it'll define my iou images "physical connection".
  scroll-down for explanation on how to predefined it.

Step-1: Container-ing. 

Put all extracted sources into kali. Extracted means out of .zip .7z anything. 

user@mchn:~$ cd /opt/ 

user@mchn:/opt$ sudo mkdir /iou/  (non-propetiary name)

user@mchn:~$ cd iou 

user@mchn:/opt/iou$ sudo cp /home/me/Downloads/i86bi_linux* ./ 

user@mchn:/opt/iou$ sudo cp /home/me/Downloads/wrapper-linux ./ 

user@mchn:/opt/iou$ sudo cp /home/me/Downloads/iougen ./ 

user@mchn:/opt/iou$ sudo chmod a+x ./* (makes sure all are executable)

Step-2: Dependencies. 

This is the hard part. Cisco developed iou back in the 2012-ish, while I’m using a 2020 distro. So it’s a must for me to create dependencies into kali library. 

First of all, I need 2 more files to download: libcrypto.so.0.9.8 & libcrypto.so.4 <= thank God I still found it on Kali download center. 

user@mchn:/opt/iou$ cd /usr/lib/

user@mchn:/usr/lib$ sudo apt-get install libssl0.9.8

user@mchn:/usr/lib$ sudo cp /home/me/Downloads/libcrypto.so.4 ./

user@mchn:/usr/lib$ sudo ln -s ./libcrypto.so.0.9.8 ./libcrypto.so.4

Step-3: Shortcut-ing. 

I’ll be accessing my image files from somewhere else inside kali, and for some best-practices, wouldn’t be from inside the system folders. So I need to make ‘em accessible without enclosing its full path. 

user@mchn:/usr/lib$ cd /sbin

user@mchn:/sbin$ sudo ln -s /opt/iou/i86bi_linux-ipbasek9-ms ./i86bi_linux-ipbasek9-ms

user@mchn:/sbin$ sudo ln -s /opt/iou/wrapper-linux ./wrapper-linux

Step-4: Licensing. 

To be fully applied, license file must be: 

• .iourc file. 
• Into /home/ folder. 

user@mchn:/sbin$ cd /opt/iou/iougen 

user@mchn:/opt/iou/iougen$ iougen (‘run’ it to generate license)

[License] 

mchn = 1234567890123456; (differ to each machine names)

Write it to .iourc file! 

user@mchn:/opt/iou/iougen$ cd /home/me/ 

user@mchn:/home/me$ vi .iourc 

Step-5: Don’t tell cisco ;) 

Since it was a ‘beta’ app -well at least when it first came up in 2012- we should reroute updates regarding iou NOT to cisco..  

user@mchn:/opt/iou/iougen$ sudo vi /etc/hosts 127.0.0.1 xml.cisco.com 

4. Getting start with the lab.. 

Step-1: Lab folder. 

Better prepare dedicated folders for lab files. I’m kinda organized person, so I liked my folder be hierarchical.. ioulabs/route/static/101 so on.. 

Step-2: Starting the device(s). 

Cisco made a file named ‘ioustart’ as its control-plane. This file needs modifications every time its parameters changes. 

user@mchn:~$ cd ../labfolder/  

user@mchn:/labfolder$ ./ioustart 

user@mchn:/labfolder$ cat ./ioustart  

wrapper-linux -m i86bi_linux-ipbasek9-ms -p 2100 -- -e 1 -s 0 -c generic 100 & 

wrapper-linux = must, as a caller to iou system. 

image file = must, device’s image to load. 

2100 (or any available port) = must, linux process ID to be use during lab. 

-e = must, set amount of ethernet interfaces to be use. 1 set interface = 4 virtual ports. 

-s = must, set amount of serial interfaces to be use. 1 set interface = 4 virtual ports. 

generic = good-to-have, devices’ initial configs. 

100 or any I'd like to put = must, pointer to be use for topology reading. 

& = must, end-of-process. 

Step-3: Topology. 

Topology is written into file called ‘NETMAP’, iou took this file to read devices physical connection. 

user@mchn:/labfolder$ cat ./ioustart 

wrapper-linux -m i86bi_linux-ipbasek9-ms -p 2100 -- -e 1 -s 0 -c generic 100 & 

wrapper-linux -m i86bi_linux-ipbasek9-ms -p 2200 -- -e 1 -s 1 -c generic 200 & 

wrapper-linux -m i86bi_linux-ipbasek9-ms -p 2300 -- -e 1 -s 1 -c generic 300 & 

wrapper-linux -m i86bi_linux-ipbasek9-ms -p 2400 -- -e 0 -s 1 -c generic 400 &

user@mchn:/labfolder$ cat ./NETMAP 

200:1/0 300:1/0
300:1/1 400:0/1
100:0/0 200:0/0 300:0/0 

Serial interfaces would be created after the ethernet interfaces.  1 set of interface consists of 4 virtual ports (0,1,2,3). 

Reading of the NETMAP file above would be: Line-1: Connect 200 s1 to 300 s1  Line-2: Connect 300 s2 to 400 s2 
Line-3: Connect 100 et1 to 200 et1 to 300 et1 

 Step-4: Stopping the device. 

To stop IOU running machine, can be done by kill-ing the running service.

user@mchn:/labfolder$ top

PID    USER    .....    COMMAND

xxxxx   user     .....     i86bi_Linux*

yyyyy   user     .....     i86bi_Linux*

user@mchn:/labfolder$ kill xxxxx

user@mchn:/labfolder$ kill yyyyy

or, simply by using:

user@mchn:/labfolder$ ./ioustop

KILL IOU XXXXX

KILL IOU YYYYY 

.... : Happy Learning : ....