No compromise OpenStack infrastructure with the latest version of OpenStack (Stein - Train is on its way!), designed for smooth upgrades.
We have various CPU configurations depending on your needs.
Various bandwidth options and public IP block sizing are available.
General purpose, throughput optimized, and performance optimized volume types with volume snapshots and backups available.
Consulting is available for every aspect of the infrastructure related to operations and maintenance.
CentOS and Ubuntu Linux and Windows images.
Import/export images without limitations.
Concerns over privacy, data protection, and passing audits are typical reasons for companies to choose private clouds over public clouds, but there are other reasons, including the price/performance ratio. Private clouds can be built with specific infrastructure that caters to a particular need, with the design focused on these specifics, whereas public clouds try to accommodate every need by adding more flavors (instance types in AWS terminology). Having enough inventory of each flavor is tough, which is why providers need to be "hyperscale" to accommodate the need. However, even with the vast array of flavors, they will never have the flexibility to accommodate every need, much less with the low-latency requirements of some applications.
There is a huge cost to being a hyperscale provider, not just to keep up with demand, but to also maintain inventory that is unused, paying for the hardware and resources to keep that inventory operational. Customers pay a significant price for this flexibility. If flexibility is not part of a project's specifications, a private cloud can easily beat the price of a public cloud solution.
One benefit of private clouds comes from the access rights of the end user. Under the right circumstances, Genesis Private Cloud clients can have root access to the cloud, allowing granular control over how the cloud operates, including potentially how the cloud connects to on-premise resources. This may also be required for security reasons, where low-level audits of the network and storage is required.
Finally, unexpected, and forced, technology changes can massively disrupt an operation, which happens with public cloud and SaaS providers often. Private clouds can be as dynamic or static as needed, keeping up with the latest technologies, or a static configuration can be left alone for years, behind appropriate firewalls and proxies.
OpenStack includes a Web UI, CLI, REST API, and SDKs for all functions within the platform.
In addition, OpenStack includes an orchestration system called HEAT, which allows clients to launch multiple composite cloud applications based on templates in the form of text files that can be treated like code, very similar to AWS CloudFormations.
OpenStack is also compatible with Terraform.
A Genesis Private Cloud is managed just like our Genesis Public Cloud, where Genesis manages the root level of the system. Under certain circumstances, root access can be provided.
OpenStack itself is a distributed application and consists of many components that are distributed across physical servers running Linux. Management of distributed applications is typically done with containers, which provide an abstract layer between the operating system and application code. Code running inside a container are simply isolated from all other code running inside other containers, since they each see only a single copy of the operating system. Containers also allow for quick deployment and destruction of code, leaving no trace that the code ever existed after destruction.
Our OpenStack deployment uses Kolla Ansible for reliable and repeatable container deployments of OpenStack's components. This also provides for easy scalability where additional nodes can be added with ease, under most circumstances. Security is also inherent in the design since code cannot be changed inside the container, only configuration data, which resides on ephemeral container volumes.
Since a private is dedicated, the only reason to be concerned with hyperthreading is if your own workloads have to mitigate MDS and other vulnerabilities related to hyperthreading. For example, you may have your own customer VMs running on the platform. It would be adviseable to disable hyperthreading under this circumstance. However, if you operate your own VMs with a single trust domain, and the performance of hyperthreading is beneficial, then enabling hyperthreading is practical. This is one of the benefits of private clouds - choice to do what is best for your environment.
Yes, this is available. This provides dedicated CPU and Memory resources with shared switching, shared storage, and a shared control plane, so it is not as segregated as Genesis Private Cloud infrastructure, but this can accommodate the requirement of various audits without the expense of a fully-dedicated cloud.
All Genesis Private Cloud configurations are custom, so we need to provide a quote based on the requirements after some design discussions. We have a small design for approximately $3,700/month with a 36-month commit. All Genesis Private Clouds require a commit of at least 24 months, with discounts for longer terms and pre-payment.
This depends on the requirements, but it is very common to include some amount of spindle-based object storage for backups.
Yes - forward and reverse DNS are supported, so you can configure your public DNS records and respective reverse DNS entries in OpenStack and then point your domain's WHOIS record to the authoritative DNS servers that are part of your Genesis Private Cloud. Note that a /24 public IP block is required for this.
Yes, we support an MTU of up to 9100, so you can easily port applications that require a standard jumbo frame size of 9000, or encapsulate traffic easily without dealing with smaller-than-normal MTU issues.
Yes. We can then provision OpenStack to use IPs from these blocks as floating IPs, and you can point your blocks' authoritative reverse DNS servers to OpenStack so reverse DNS will work properly.
Windows licensing for Genesis Private Cloud requires licensing each core of each physical server that is zoned for Windows licensing. We can create rules to allow only specific operating system images to be deployed to a specific zone of machines, limiting the number of physical servers that require licensing, allowing Linux VMs, for example, to run on a separate set of physical servers from the Windows VMs.
Yes, but we would need to evaluate the scope of work required for the migration and provide a proposal. Free free to contact us if you have any questions or would like to discuss options.
FOLLOW US
CONTACT US
LEGAL
Copyright © 2020 Genesis Hosting Solutions, LLC. All Rights Reserved.