August 2019 - Seite 28 von 89 - Cloud Computing Köln

The Enterprisers Project always has terrific information that can help you and your team communicate those complex cloud computing concepts to the C-levels. This past week, they published an excellent article describing what exactly secrets are in Kubernetes, how to manage them and what security benefits they provide. From the article:
Kubernetes Secrets defined, three ways
Let’s add a few more clear-cut definitions of Secrets to your arsenal that should help you either get up to speed as necessary or explain the concept to others on the team.
1. “As applications run in Kubernetes, apps need credentials to interact with the surrounding infrastructure or another application. Those credentials are kept in Kubernetes, and your applications can use a credential by specifying the name of a Secret as opposed to having the application keep the contents of the Secret.” –Eric Han, VP of product management at Portworx. (Han was also the first Kubernetes product manager when it was still an internal system at Google.)
2. “Kubernetes Secrets provide a means to protect sensitive information in a way that limits accidental exposure and provides flexibility in how the information is utilized. Secrets are only accessible to Pods if they are explicitly part of a mounted volume or at the time when the Kubelet is pulling the image to be used for the Pod. This prevents the need to store sensitive information in a Pod image, which mitigates the risk that data is compromised and makes it easier to vary things like credentials, cryptographic keys, etc. for different pods.” –Jonathan Katz, director of customer success & communications at Crunchy Data
3. “Kubernetes Secrets are a way to store and distribute sensitive information – think passwords, or an SSL certificate – that are used by applications in your Kubernetes cluster. Importantly, the declarative nature of Kubernetes definitions allows third-party solutions to be integrated with the Secret management.” –Gary Duan, CTO at NeuVector
Read the full article here.
The post From the Enterprisers Project: What Are Kubernetes Secrets? appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift

22. August 2019

da Agency

DR for cloud: Architecting Microsoft SQL Server with GCP

Database disaster recovery (DR) planning is an important component of a bigger DR plan, and for enterprises using Microsoft SQL Server on Compute Engine, it often involves critical data. When you’re architecting a disaster recovery solution with Microsoft SQL Server running on Google Cloud Platform (GCP), you have some decisions to make to build an effective, comprehensive plan. Microsoft SQL Server includes a variety of disaster recovery strategies and features, such as Always On availability groups or Failover Cluster Instances. And Google Cloud is designed from the start for resilience and availability. There are several types of data centers available within GCP where you can map SQL Server’s availability features based on your specific requirements: zones and regions. Zones are autonomous data centers co-located within a GCP region. These regions are available in different geographies such as North America or APAC. However, there is no single disaster recovery strategy to map Microsoft SQL Server DR features to Google Cloud’s data center topology that satisfies every possible combination of disaster recovery requirements. As a database architect, you have to design a custom disaster recovery strategy based on your specific use cases and requirements.Our new Disaster Recovery for Microsoft SQL Server solution provides information on Microsoft’s SQL Server disaster recovery strategies, and shows how you can map them to zones and regions in GCP based on your business’s particular criteria and requirements. One example is deploying an availability group within a region across three zones (shown in the diagram below). For successful DR planning, you should have a clear conceptual model and established terminology in place. In this solution, you’ll find a base set of concepts and terms in context of Google Cloud DR. This includes defining terms like primary database, secondary database, failover, switchover, and fallback.You’ll also find details on recovery point objective, recovery time objective and single point of failure domain, since those are key drivers for developing a specific disaster recovery solution.Building a DR solution with Microsoft SQL Server in GCP regionsTo get started with implementing the availability features of Microsoft SQL Server in the context of Google Cloud, take a look at this diagram, which shows the implementation of an Always On availability group in a GCP region, using several zones:In the new solution, you’ll see other availability features, like log shipping, along with how they map to GCP. In addition, features in Microsoft SQL Server that are not deemed availability features—like server replication and backup file shipping—can actually be used for disaster recovery, so those are included as well. Disaster recovery features of Microsoft SQL Server do not have to be used in isolation and can be combined for more complex and demanding use cases. For example, you can set up availability groups in two regions with log shipping as the transfer mechanism between the regions.Disaster Recovery for Microsoft SQL Server also describes the disaster recovery process itself, how to test and verify a defined disaster recovery solution, and outlines a basic approach, step-by-step. Learn more about SQL Server on GCP and check out all of our solutions.
Quelle: Google Cloud Platform