Transcript
As James was saying earlier, we are hardware agnostic. So in this environment that I have set up for the demo, I'm currently just on a couple of small HPE servers. I have a 512 gig drive that is my boot drive. I have Proxmox installed on it, and then also install our OVA for our software-defined storage on that drive as well. And then I have two NVMe 3.84 terabyte drives that are presented as raw devices to our software. So we are hardware agnostic. These are the servers that I have set up for this demo environment. So if we move over here to Proxmox, in the Proxmox environment, it is set up, we've gone through and set up our bridge switch for our management network, and then also a switch for our iSCSI traffic. So in most of the environments that we work in at the edge, when we're setting up our iSCSI storage network, we have several options. In most of our customers, they just do a crossover cable between the two servers, and then that network is used for mirroring and for synchronization. You can also go through a switch network. It depends on the network that you have available. You see in remote locations, edge locations, they have their management network coming in. And instead of having to deal with the additional cost of switch ports for their storage network, we just do a crossover cable between those two servers, which makes it a lot less complicated than having to go through your switch ports. So we do support 1G, 40G, 10G, 100G, whatever network you have available to us. And it is dependent on what kind of drives you're running, the applications that you're running. If you're running a couple of spinning disks and maybe running an environment where you're running maybe a file and a print and maybe a DNS server or maybe a light application, you may be able to get away with a 1G network and spinning disk. If you're running NVMEs and running multiple VMs, databases, or things like that, then it's recommended 10G or greater for those type of environments for your performance. So in this environment, I have it set up where I have our software installed. So basically, you install your Proxmox on your local boot drive. And then from your local boot drive, we'll import our OVA. Once we import our OVA, then we'll go into that OVA. We will set up our hardware, create a virtual switch, our bridge switch, same as is set up currently on the Proxmox install that we'll use for our management. And then we'll also set up another switch for our dedication for our storage network between the two hosts. And that will be for the storage, traffic, mirroring, and synchronization. So once that's set up, if we go to our console, by default, when you install the OVA, the OVA will boot DHCP. So we would go to my network devices. And from our network devices, we would create our management IP address and then an IP address for our storage network for our synchronization. So I have a 10.10.194.5 address set up for my management. Once that address is set up, then we can go to the web interface. And once you hit the web interface, the first time you log in, you will be presented with a first boot wizard. The first boot wizard will ask you the name of the box, what IP address or the name of the box that you want. You put in the name of the box, your DNS, and then it goes through and asks you for your license. So from within the licensing, our licenses are based on usable capacity in 2 terabytes, 6, 12, 24, 48, or unlimited. So once you install the license key, put in your license key, and then click Connect. And that will connect to our licensing server and upload your license to that server. If you do not have internet connectivity, then you can go to our licensing server, put in the serial number and the license key, and it will generate a offline license file. And then you would just go down, choose License File, upload that license file, and then it would upload the licensing for this virtual storage appliance. If we look at the features, we have the mirroring enabled. Excuse me. Mirroring is for our storage for the synchronization and mirroring between both of the hosts. Capacity is based on the usable capacity in the 2 terabytes, 6, 12, 24, 48, or unlimited. When we start looking at the capacity, you can either present us that capacity via a RAID controller. You can have a RAID controller on your server, create a RAID array, present us that RAID array, and we can use that as a capacity layer. Or if you have a server that doesn't have a RAID controller in it, you can present the drives to us through RDM, and then we can create a RAID 0, RAID 1, or RAID 10 of those drives. And then we have SSD and memory caching. So if you have applications that you're running, if you're running spinning disks and you need some additional performance, we can put a cache layer in front of those. It's not required. It is just something based on the performance that you need in your environment. What we recommend if you're running cache is that cache is 10% of your capacity. So if you're running a 6 terabyte capacity layer, we would recommend 10% of that, or 600 gigs as a cache layer in front of that. So we have memory caching and SSD caching. If both of those are enabled, then we have what we call predictive caching, and the hottest running applications will be preloaded into memory. And then as they cool down, it'll move from memory to your SSD caching and then flush them out to your standard drives. We also have volume encryption, which is data at rest. It is a feature that can be enabled on our software. It is built into the software. If you need encryption, then we just set the flag for encryption, and then you would need a key management server to manage those encryption keys. We do have a product called SVKMS that does a encryption key management, and it is FIPS 140-2 compliant. So that's basically setting up the licensing for our SV-SAN product. Once the licensing is set up, then you would go in and validate your network, set up your interfaces for your server. Let me go. So I have my interfaces set up where I have my management interface, and then I have my iSCSI connection interface that I use for my synchronization and mirroring between my two hosts. If I look at this server, the devices in this server, I have my boot drive, and then I have the two 3.4 terabyte drives that I'm using for my capacity layer. On these servers, there's not a RAID controller, so what I did was take those two drives, created them together, and I put them in a RAID 1 with our software RAID, so there is some redundancy. If I lose a drive, I'll be notified that a drive is offline, and then I can go through the process to remove and replace that drive. So once your pools are created, if I go to my pool here, you can see the two hosts that I've got that are part of that pool. If I go to my connections for this pool, if I go to my targets, my targets will show the datastore that I have created that is being mirrored between both of my hosts, both of my SV-SAN hosts, and my synchronized between both of those. We have our witness. Our witness is used for the quorum within the cluster. Our witness is used when the cluster first boots up. It's used to validate that the cluster is up. It's used to validate that the cluster is in service on a Windows box, a Linux box, a Raspberry Pi, or even in the cloud. So depending on whether you want your witness local, remote, or in the cloud, our witness is not in the datapath. Basically, our witness is used when the cluster first comes up. We've got a single witness that's used for the quorum to establish who's in charge of the cluster synchronizations and rights within the cluster. Once that's established, then all the witness does is a heartbeat to each of the hosts to validate that they are up. Our witness can manage up to 8,000 clusters from the single witness. He goes through and does a heartbeat to each of those. If he can't communicate with one of the hosts, he can talk to his partner. And if he can't, then the host that is up enacts his journal file, and he starts keeping track of all the changes that are committed while that other host is down. And then when that host comes back up, it will synchronize the missed data with that host to ensure your data integrity between those two hosts. So this is SV-SAN set up and configured with our discovery for our environment. If I go to my discovery, it shows you my witnesses that I have available in my environment. Like I said, you can manage up to a thousand clusters from a single witness. And then this is the other host that is in my environment. If I go to my events from my events tab, I can see my email notifications, SNMP. If I'm doing SNMP, I can go to my SNMP and download the MIBs for my SNMP directly from within the SV-SAN. So that shows you my events that are set up in this environment. So within Proxmox itself, if I go back to Proxmox, I can see my SV-SAN environment that's running and go to my console, see my console. If I go, this is the SV-SAN storage that is being presented to Proxmox via our SV-SAN software presented as iSCSI storage. So, and then these are the VMs that I'm running in this environment. So the VMs that I'm running, I can click on a VM, go to that particular VM that's running. This is just a Linux Ubuntu VM that's running. Let me log in. So I can run a ping on both of these VMs and I can see that I'm running this VM to my other host. And if I want, I can just click on Migrate and I'll migrate this VM from host one over to host two, click Migrate, and I'll go through the process to migrate this VM. As you can see in the background, it is still pinging. Then this screen will, once that VM is moved from host one over to host two, the screen will go blank and then it will present that VM over on host two. And you can see by the number of pings that most time it doesn't even drop a ping when it changes from one host to the other, or we've seen some instances where it drops a minimal number of pings. So now it's back over on host number two. And as you can see, it's still pinging in that environment. Within SV SAN, so we do the mirroring between those two hosts. If a host goes down, then those VMs automatically restart on the other host in the environment. So it's kind of quick. If you need to do snapshots, you can do snapshots just as you would through any other Proxmox environment. As James was talking about earlier, this is a two node configuration so that you don't need to use Ceph. We use our witness, either local remote or in the cloud. Yeah.
