Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

Microsoft Ignite 2017 - SQL Server on Kubernetes, Swarm, and Open Shift

Cargando en…3

Eche un vistazo a continuación

1 de 47 Anuncio

Más Contenido Relacionado

Presentaciones para usted (20)


Similares a Microsoft Ignite 2017 - SQL Server on Kubernetes, Swarm, and Open Shift (20)

Más de Travis Wright (14)


Más reciente (20)

Microsoft Ignite 2017 - SQL Server on Kubernetes, Swarm, and Open Shift

  1. 1. The New Reality 3 Data and Agility are the only hope of survival
  2. 2. 4 Longevity is not a given anymore
  3. 3. Disruption happens practically overnight 5
  4. 4. Nature of Software Delivery Has Changed
  5. 5. DevOps Principles in Focus 7
  6. 6. 9
  7. 7. Container Benefits 9 This is not a fad!
  8. 8. …but wait… 10
  9. 9. Docker Databases 11 Most of the most popular images are databases Postgres: 10M+ pulls Mysql: 10M+ pulls Redis: 10M+ pulls Mongo: 10M+ pulls SQL Server on Linux has had ~2M+ pulls in the first 10 months
  10. 10. Persisting Storage 12 Mount a volume to the host Local storage Remote storage Mount a container volume docker run … -v /my/host/dir:/my/container/dir … docker create -v /mydata --name mydatacontainer … docker run --volumes-from mydatacontainer … Read this!
  11. 11. Build & Test Locally in Dev Environment 13 Build locally on Windows, Linux, or macOS Windows Linux Docker containers using Docker for Windows Windows containers on Windows 10 Anniversary Edition+ macOS Linux Docker containers using Docker for Mac Linux Use Docker Engine natively There are other container engines like LXC Use for demo today
  12. 12. Application Deployment Patterns Using Containers 14 SQL Server App 1 App 2 SQL Server App 1 SQL Server + App 1 Centralized SQL Server Docker Compose Monolithic App or Microservice
  13. 13. Real World Example – SQL Server Team 18 SQL Server Engineering Team uses Kubernetes in Azure VMs for automated testing of SQL Server on Linux Automated build process creates the container image Extended existing test system to handle provisioning and test execution/targeting ~700 containers per test run, usually once per day 150 VM hosts in Azure; 128 GB/8 cores 20+ containers/VM in some cases High density, each SQL Server container listens on a different
  14. 14. Real World Example – DV01
  15. 15. NETWORKING
  16. 16. Container to Container on the Same Host 2 4 OVS PACKET FLOW NODE POD 1 veth0 br0 eth0 POD 2 veth1 vxlan0
  17. 17. NODE 2 NODE 1 2 5 OVS PACKET FLOW POD 1 veth0 br0 vxlan0 POD 2 veth0 br0 vxlan0 eth0 eth0 Container to Container on the Different Hosts
  18. 18. Container Connects to External Host Container to Container on Different Hosts 2 6 OVS PACKET FLOW NODE 1 POD 1 veth0 br0 tun0 External Host eth0
  20. 20. ROUTE SPLIT TRAFFIC SERVICE A App A App A SERVICE B App B App B ROUTE 10% traffic 90% traffic Split Traffic Between Multiple Services For A/B Testing, Blue/Green and Canary Deployments
  21. 21. “For which workloads or application use caseshave you used/do you anticipate touse containers?” DataApps 77% CloudApps 71% Systems of Engagement 62% Systems of Record 62% Web andCommerce Software 57% MobileApps 52% SocialApps 46% Scalable, Cost Effective, Distributed Storage for Containers
  22. 22. ● Persistent Volume are tied to a piece of network storage ● Provisioned by an administrator either statically or dynamically ● Allows admins to describe storage and users to request storage PERSISTENT STORAGE NFS GlusterFS OpenStack Cinder Ceph RBD Azure Blob Fibre Channel Azure File Azure Disk iSCSI
  23. 23. PROJECT POOL OF PERSISTENT VOLUMES PERSISTENT STORAGE NFS PV iSCS I PV NFS PV Admin User register PV create claim NFS PV GlusterFS PV Pod claim Pod claim Pod claim Ceph RBD PV
  24. 24. 3 3 DYNAMIC VOLUME PROVISIONING Admin User define StorageClass create claim: Fastest Slow Azure-Disk Fast AWS-SSD Fastest NetApp-Flash NetApp Provisioner AWS Provisioner Pod claim PV OpenShift PV Controller provision Azure Provisioner bound
  26. 26. NODE MASTER ● Secure mechanism for holding sensitive data e.g. ○ Passwords and credentials ○ SSH Keys ○ Certificates ● Secrets are made available as ○ Environment variables ○ Volume mounts ○ Interaction with external systems ● Encrypted in transit ● Never rest on the nodes 3 6 SECRET MANAGEMENT Container Distributed Store Container
  27. 27. Secret Example
  28. 28. DevOps: CI/CD with Microsoft SQL Server 2017 Tomorrow at 12:30 – 1:45, Hyatt International
  29. 29. Key Docker Terminology and Commands 45 Image – A definition. Defines what software is included and how it runs. Container – A running instance based on the image. docker pull – download an image from a Docker respository docker run – create a container from an image docker ps – list all locally running containers docker images – list all locally cached images You do not “install” a Docker container! 
  30. 30. Master.mdf ContosoUniversity.ldf ContosoUniversity.mdf db-prod:latest

Notas del editor

  • A route exposes a service at a host name, like, so that external clients can reach it by name.
    DNS resolution for a host name is handled separately from routing. Admin may have configured a DNS wildcard entry that will resolve to the node that is running the OpenShift Container Platform router
    Pods running on OpenShift, don’t need to go through the routing layer and can interact with each other directly through the services.
  • OpenShift Container Platform leverages the Kubernetes persistent volume (PV) framework to allow administrators to provision persistent storage for a cluster. Using persistent volume claims (PVCs), developers can request PV resources without having specific knowledge of the underlying storage infrastructure.
    OpenShift Container Platform supports a growing list of storage plugins for using various storage solutions.
    Note that high-availability of storage in the infrastructure is left to the underlying storage provider.
  • Administrators define a pool of Persistent Volumes (PV) which are backed by network storage solutions like NFS, iSCSO, AWS EBS, etc and make them globally available in the OpenShift cluster.
    Users within their projects can create a Persistent Volume Claim (PVC) in order to request a PV to be available within their pods. In the pod definition, a developer can refer to the PVC and mount the requested persistent volume inside the pod at an arbitrary path.
    If a pod gets restarted, OpenShift mounts the same persistent volume into the pod again so that the pod data is available. PVs outlive the containers that were using them.
  • Dynamic provisioning allows provisioning persistent volumes on-demand when users request it rather than admins predefining them in advance
    StorageClass is a blueprint of how to provision persistent volumes on a network storage. OpenShift provides a set of provisioners that determine what volume plugins should be used for provisioning the volumes. OpenShift also supports third-party plugins that are not part of Kubernetes, such as NetApp Trident
    Admins creates a catalog of StorageClasses available in the OpenShift cluster. StorageClass names are arbitrary names to communicate their characteristics
    Users can create a Persistent Volume Claim and specify the name of a StorageClass to instruct OpenShift on the type of persistent volume that should be provisioned for the them
  • The goal of container-native storage (CNS) is to provide a solution that runs Red Hat Gluster Storage software as containers inside OpenShift as Kubernetes pods. CNS enables OpenShift users to add reliable, safe, and shared persistent storage to their projects. It allows OpenShift administrators to deploy and manage their GlusterFS storage clusters quickly and easily. OpenShift administrators can easily create GlusterFS volumes using Heketi, a GlusterFS multicluster volume manager, and then register the volume availability with OpenShift by submitting a persistent volume claim (PVC). GlusterFS also supports dynamic provisioning of persistent volumes and removes the need for administrators to define and create PVs in OpenShift upfront and have them created on-demand instead when users request a PV.
    OpenShift users can take advantage of these GlusterFS volumes by submitting an OpenShift PVC, which is then bound to an appropriate persistent volume. When users employ their claim, OpenShift invokes the GlusterFS volume plug-in that mounts the appropriate GlusterFS volume from the node running the pod to enable the container referenced in the claim to access the desired volume.
    The solution supports collocating other OpenShift (Kubernetes) application pods on the same OpenShift nodes as the Red Hat Gluster Storage pods, in a “hyper-converged” configuration.
    Red Hat Gluster Storage pods can be deployed on any OpenShift nodes within the cluster that have one or more block devices with many logical volumes defined which are used as the bricks for volumes provided by Red Hat Gluster Storage pods.

  • Having an easy-to-use, secure-by-default secret distribution mechanism is exactly what developers and ops need to solve the secrets management problem once and for all
    Because secret objects can be created independently of the pods that use them, there is less risk of the secret being exposed during the workflow of creating, viewing, and editing pods.
    A secret is only sent to a node if a pod on that node requires it. It is not written to disk. It is stored in a temporary file-storage facilities (tmpfs). It is deleted once the pod that depends on it is deleted.
    Secrets are stored as plaintext in etcd however the etcd storage can be encrypted to remove the security risk