You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/en/docs/concepts/kaktus.md
+11-2Lines changed: 11 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ description: Learn about Kaktus HCI node.
4
4
weight: 6
5
5
---
6
6
7
-
**Kaktus** stands for **K**owabunga **A**ffordable**K**vm and **TU**rnkey **S**torage (!!), basically, our Hyper-Converged Infrastructure (HCI) node.
7
+
**Kaktus** stands for **K**owabunga **A**mazing**K**VM and **TU**rnkey **S**torage (!!), basically, our Hyper-Converged Infrastructure (HCI) node.
8
8
9
9
While large virtualization systems such as VMware usually requires you to dedicate servers as computing hypervisors (with plenty of CPU and memory) and associate them with remote, extensive NAS or vSAN, providing storage, Kowabunga follows the opposite approach. Modern hardware is powerful enough to handle both computing and storage.
10
10
@@ -21,7 +21,16 @@ If you're already ordering a heavy computing rackable server, extending it with
21
21
- several local disks, to be part of a region-global [Ceph](https://ceph.io/en/) distributed storage cluster.
22
22
- the **Kowabunga Kaktus agent**, connected to **Kahuna**
23
23
24
-
**Kaktus agent** controls the local **KVM** hypervisor through **libvirt** backend and the local-network distributed **Ceph** storage, allowing management of virtual machines and disks.
24
+
From a pure low-level software perspective, our virtualization stack relies on 3 stacks:
25
+
26
+
-**Linux Network Bridging driver**, for virtual interfaces access to host raw network interfaces and physical network.
27
+
-**Linux KVM driver**, for CPU VT-X extension support and improved virtualization performances.
28
+
-**RBD (Rados Block Device) driver**, for storing virtual block devices under distributed Ceph storage engine.
29
+
QEMU drives these different backends to virtualize resources on to.
30
+
31
+

32
+
33
+
Now **QEMU** being a local host process to be spawned, we need some kind of orchestration layer on top of that. Here comes **libvirt**. libvirt provides an API over TCP/TLS/SSH that wraps virtual machines definition over an XML representation that can be fully created/updated/destroyed remotely, controlling **QEMU** underneath. **Kaktus agent** controls the local **KVM** hypervisor through **libvirt** backend and the local-network distributed **Ceph** storage, allowing management of virtual machines and disks.
25
34
26
35
{{< alert color="success" title="Note" >}}
27
36
When configured for production-systems, Ceph storage cluster will be backed by cross-zones N-times (usually 3) replicated high-performance block devices, providing virtually infinitely scalable and resizeable disk volumes with byte-precision.
Copy file name to clipboardExpand all lines: content/en/docs/concepts/koala.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ weight: 4
6
6
7
7
**Koala** is Kowabunga's WebUI. It allows for day-to-day supervision and operation of the various projects and services.
8
8
9
-

9
+

10
10
11
11
But should you ask a senior DevOps / SRE / IT admin, fully automation-driven, he'd damn anyone who'd have used the Web client to manually create/edit resources and messes around his perfecly maintained CasC.
We'll start with a single **Kahuna** instance, with public Internet exposure. The instance's hostname will be **kowabunga-kahuna-1** and it has 2 network adapters and associated IP addresses:
0 commit comments