Life happens, and so does the Hybrid Cloud. If your company is successful enough, it’ll likely have workloads spread across different public cloud providers and on-premises servers. For winning in these scenarios, you need the power of open source.
Join us in this session to witness how technologies like Kubernetes and Skupper can turn the odds in your favor. You’ll see how effectively you’ll achieve requirements like cost management, failover, resiliency, and others yet maintaining your data safe.
Abstract: Kubernetes has high availability built into it, but the default settings may not be optimal for certain workloads. In this short session we’ll be looking at what happens to pods in Kubernetes when the node that they are running on fails.
When a node goes into a not ready state, Kubernetes by default, will wait for 5 minutes to move any pods running on that node to a new healthy node.
We’ll discuss how this timing can be adjusted and then have a look at this in action!”
One thing I wanted to ask…with PVs on downed node..they don’t move across until that node is brought up or removed from the cluster (tested in both AKS and EKS).
It’s something that has been holding us back from deploying SQL Server on K8s….the only option we’ve found is a third-party tool from Pure Storage called Portworx.
Abstract: The CAP theorem is widely known for distributed systems, but it’s not the only tradeoff you should be aware of. For datastores there is also the FAB theory and just like with the CAP theorem you can only pick two:
Fast: Results are real-time or near real-time instead of batch oriented.
Accurate: Answers are exact and don’t have a margin of error.
Big: You require horizontal scaling and need to distribute your data.
While Fast and Big are relatively easy to understand, Accurate is a bit harder to picture. This talk shows some concrete examples of accuracy tradeoffs Elasticsearch can take for terms aggregations, cardinality aggregations with HyperLogLog++, and the IDF part of full-text search. Or how to trade some speed or the distribution for more accuracy.
Data Management is required across the board when it comes to any platform, we could be talking about Virtualization, Cloud (IaaS, PaaS, SaaS, etc), Cloud-Native, and Legacy and sometimes all of these platforms are linked together to serve the end-user.
Data Management consists of many different facets including Backup, Recovery, Migration, and leveraging that data as part of another use case that does not interfere with the production environment.
In this session we are going to focus on protecting stateful workloads in your cloud-native Kubernetes environment, the importance of making sure your data services are protected but also the capabilities available to enable easy migration between multiple different Kubernetes clusters and environments.
Database not running in Kubernetes? That is fine, we also have a unique way of being able to protect your data services that reside outside of the Kubernetes cluster.
If we have time, we can also touch on the ability to add this to your continuous deployment process to ensure that your data service is also protected before any code change.