Compute Services in Cloud PDF

COMPUTE SERVICES IN CLOUD 1 OUTLINE  Type of compute services  Virtual Machine Types and variations (Service account) Instance Groups Use cases  Micro-service engine  Standard  Flexible  Use cases  Serverless engine  Event, triggers, functions  M...

COMPUTE SERVICES IN CLOUD 1 OUTLINE  Type of compute services  Virtual Machine Types and variations (Service account) Instance Groups Use cases  Micro-service engine  Standard  Flexible  Use cases  Serverless engine  Event, triggers, functions  Managed container clusters (Kubernetes)  Concept, structure and abstractions  Use cases  Lab 2  TYPE OF COMPUTE SERVICES 1.Virtual 2. Micro- Machine service Engine (E2/EC2) (Elastic Beanstalk/ AppEngine) 3. Managed 4. Serverless container Engine clusters (Lambda/ (Kubernetes Cloud ) Functions) 3 VIRTUAL MACHINE (INSTANCE)  All components of a traditional computer are virtualized for customization CPU Memory Hard-disk  These virtual machines run in CSP’s data centers worldwide through fiber network  Support different operating systems Windows Linux (Ubuntu, Redhat, etc)  Pre-defined machine types Micro (0.2 vCPU) to Super (96vCPUs) compute power Compute-optimized or memory-optimized N1, E2, Mac, T4g, T3, A1,...... 4  PROVISION AN INSTANCE  Choose vCPU and memory Each vCPU is treated as a single physical CPU 1 or more vCPUs are assigned to a VM (even number) Total number of available vCPUs depends on the zone Standard pre-defined machine types have balanced CPU and memory ratio HighCPU or Highmem machine type are for special Pre-defined machine types computational purpose  Customization on creation * Standard When pre-defined machine type does not match the High Memory desired capacity Incurred cost will be adjusted accordingly on-the-spot High CPU  Basic rules for provision memory Shared-core Memory should be between 0.9GB/vCPU to 6.5GB/vCPU Total memory should be a multiple of 256MB Mega Memory *: change the machine type or adjust resources after provision may require shutdown or terminate the machine 5 6 PROVISION AN INSTANCE  Local SSD  Physically attached to the host machine (VM) VM  High IOPS (2.4mil/1.2mil for read/write, throughput Local up to 9.3Gbps) SSD  Very low latency compare to other block storage Persistent options Disk Persistent  For temporary storage such as cache or scratching Disk processing space  Attach up to 24 local SSD partitions for 9TB of total space  Persistent Disk  SSD or HDD  Attach to VM(s) or Kubernetes Engine  Transparently resize  Support simultaneous readers (data sharing among VMs)  Snapshots are geo-replicated for restore in all regions by default  Exist even after the VM is deleted 7 PROVISION AN INSTANCE (CONT.D)  Choose network interface  Choose VPC (or use custom VPC)  Choose Firewall Rules (e.g. allowed protocols, IPs)  Meta Data and User Data  Meta Data describes the instance (e.g. IP, hostname, image-ID) Curl http://169.254.169.254/latest/meta-data/  User Data is customer script run in the instance #!/bin/bash yum update -y yum install -y httpd systemctl start httpd systemctl enable httpd echo "Hello World from $(hostname -f)" > /var/www/html/index.html 8 PRE-EMPTIBLE VM AND SHIELDED VM  Pre-emptible VM Run 24 hours before shut down by CSP Can be shut down anytime while running Running processes have 30s to shut down gracefully before VM shutdown Up to 80% cheaper than standard VM Pre-emptible VM can be used for most compute services (e.g. EC2, Fargate, RDS, EMR)  Shielded VM VM with enhanced security controls Secure boot vTPM (virtual Trusted Platform Module) Integrity monitoring – compares the boot measurements with a trusted baseline and return true if the results match and false otherwise 9 INSTANCE GROUP  Clusters of VMs managed as a single unit  Managed instance group Must be identical VMs created by the same instance template Auto-scaling, load balancing, auto-healing, auto-update  Unmanaged instance groups VMs may not be identical Used to support preexisting cluster configurations for load balancing tasks 10 EXAMPLE: INSTANCE GROUP WITH ELB 11 VM INSTANCE USE CASES  Suitable for users who need control over all aspects of a VM  It is compatible for docker/container  Easy to attach/detach storage spaces  Good option to run stateful applications, like databases  Sole tenancy is available for high security required cases  More flexible for tech-savvy to custom the system  First choice for lift-and-shift migration  Cheaper compare to fully managed services 12 ELASTIC COMPUTE ENGINE (EC2) DEMO 13 MICRO-SERVICE ENGINE  Paas service for micro services  Regional service  Fully managed  Provides health checks and automatically patches underlying OS  VMs are restarted once a week  Some platform allows user to customize their runtime environment by using Docker files (e.g AppEngine flexible)  Resource auto-scale according to workload  Load balancer is implemented by default  Usage based charging (free daily quota)  SDK for development and testing  Run on sandbox environment  Deployment $ gcloud app deploy (for GCP) $ eb create dev-env (for AWS) 14 DIFFERENCE TO VM 1. By default, SSH is disabled. 2. Limited access to storage 3. Regional resource 15 MICRO SERVICE ENGINE ENVIRONMENT AWS Beanstalk GCP AppEngine 16 USE CASES  Web and mobile backends  Suitable for applications need to scale rapidly up or down  Release different versions of the APP quickly  APP should be stateless If state really need to be maintained, store outside in a cache or database  Task queues are integrated To schedule asynchronous tasks To distributing workload  Startup time for micro-service engine is on the order of minutes, not seconds 17 MICRO SERVICE ENGINE USAGE EXAMPLE 18  SERVERLESS ENGINE  A piece of code to be triggered to complete some short operations  Triggers S3 events SNS SES CloudFormation CloudWatch Logs CloudWatch Events CodeCommit Config ……  Support languages Node.js, Python, Go, Java  There’s a limitation of serverless engine execution time. AWS Lambda functions can run up to 15min per execution. GCP Cloud Functions are timed out after 1min, but user can extend this period up to 9 minutes. 19 LAMBDA USAGE EXAMPLE 20 21 CONTAINER & KUBERNETES 22 WHAT IS A CONTAINER?  Problem  Docker  De-couple the Linux Kernel and User Space Each application may need different OS  Share Kernel and pack User Space to containers type and version, dependencies, and  Not a hypervisor, can’t virtualize across OS kernels libraries The adjust of underlying  Container OS/dependencies/libraries may result the An isolated virtual environment existing app fail to function Light (~MB) and portable Different Dev/Test/Prod environments Docker hub (https://hub.docker.com/ ) 23 CONTAINER VS VM 1. App layer abstraction 1. Hardware layer abstraction 2. Shared OS resources 2. Each VM has its own OS 3. Lightweight 3. Not lightweight: each VM has full OS, binary, libraries, etc 4. Faster boot time 4. Slow to boot 24 TYPES OF CONTAINERS Container packager Storage of docker images Open source No daemon. containerization Run in bash platform process. Container service orchestration OS image for container services Standard low- A set of 1 or more level container processes that are runtime. Written isolated from the rest of in Go. the system 25 WHY NEED KUBERNETES?  Questions How many containers should be load to a ship? Which container goes to which ship? How terminal talks to ships? And ships talk to each other? How business owners access their containers? 26 COMPONENTS OF KUBERNETES Out of cluster Node 1 kubelet Kube-proxy Control plane Pod 1 Pod 2 (@Master Node) Kube- apiserver scheduler kubelet Node 2 Kube-proxy ectd key- value store kubelet Node 3 Node 4 kubelet Kube-proxy Kube-proxy controller manager 27 MANAGED CONTAINER CLUSTERS (KUBERNETES)  Kubernetes, also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.  The 1st version of Kubernetes published at July, 2015 28 https://kubernetes.io COMPONENTS OF KUBERNETES  kube-apiserver  Front-end of Kubernetes control plane  Scale horizontally  etcd  Key-value pair information database  kube-scheduler Control Plane  Select a node to assign newly created Pods  kube-controller-manager  Node controller, job controller, endpoints controller, service account & token controller  Usually complied in a single process  Kubelet  Make sure containers are running and healthy in a Pod  kube-proxy  Maintain network rules on nodes Node  Allow network communication to the Pods from inside and outside of the cluster 29 IMPORTANT TERMS FOR KUBERNETES  Pods  Smallest computation unit managed by Kubernetes  Multiple containers should be in the same pod only if they are functionally related, and have similar scaling and lifecycle characteristics  Deployed in groups or replicas to nodes by the scheduler  Ephemeral, may be terminated if not functioning properly  Services  An abstraction with a stable API endpoint and stable IP address  For other services to interact with  Keep track of its associated pods to route calls to a functioning pod  Deployment  A desired number of pods running the same version of an application  Kubernetes maintain the healthy Pods within a deployment 30 IMPORTANT TERMS FOR KUBERNETES  ReplicaSets A controller that manages the number of pods running for a deployment Remove unhealthy pod and add new pod based on pod specification  StatefulSets Designate pods as stateful and assign a unique identifier to them Kubernetes use the identifier to track which clients are using which pods and keep them paired  Persistent volumes Decouple from ephemeral pod to store data  Ingress An object that controls external access to services running in a Kubernetes cluster Ingress controller must run in a cluster 31 WORK CHART OF KUBERNETES Service Clients (API, IP) Other Deployment services (Desired # of node) ReplicaSet/StatefulSet ingress Control Plane (kill and add pod, pair (traffic control) traffic) Node Nod kubelet e kubelet Kube-apiserver Node Kube-proxy Kube-proxy (communication) Kube-control-manager kubelet Kube-proxy pod pod Kube-scheduler pod etcd (decide which pod (DB) node to host the new pod) 32 DEPLOY A CONTAINERIZED WEB APP 33 SUMMARY 4. Serverless Engine Saas (Lambda/Cloud Functions) 2. Micro-service Engine Paas (Elastic Beanstalk/ AppEngine) 3. Managed Iaas~Paas Container clusters (Kubernetes) 1.Virtual Iaas Machine (EC2/E2) 34 CASE STUDY – DRESS4WIN  40 web application servers providing micro-services based APIs and static content  Tomcat-Java  Nginx  4-core CPUs  32 GB RAM  20 Apache Hadoop/Spark servers  Data analysis and real-time trending calculations  8-core CPUs  128GB RAM  4*5TB HDD (RAID 1)  3 RabbitMQ servers for messaging, social notifications and events  8-core CPUs  32GB RAM  Miscellaneous servers  Jenkins, monitoring, bastion hosts, security scanners  32GB RAM 35 36 LAB 1: VM CREATION  https://catalog.workshops.aws/general-immersionday/en-US/basic-modules/ 10-ec2/ec2-linux 37 LAB 2: DEPLOY AN APP  Open the Elastic Beanstalk console, and in the Regions list, select your AWS Region.  In the right top of navigation pane, click “Create Application”.  Use AWS sample code or upload your.html code in zip/war format For this lab just choose TomCat & using AWS sample code  Click “Create application”  Click on the URL to test the webpage  View logs and configuration tags  Deploy a new version of the app https://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/GettingStarted.DeployApp.html  CLI aws elasticbeanstalk create-application-version --application-name my-application --version- label v1 --source-bundle S3Bucket=DOC-EXAMPLE-BUCKET,S3Key=php-proxy-sample.zip https://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/index.html 38 LAB 3: FAMILIAR WITH LAMBDA  Create a bucket and upload a image into it To create a Lambda function from a blueprint in the console 1. Open the Functions page on the Lambda console. 2. Choose Create function. 3. On the Create function page, choose Use a blueprint. 4. Under Blueprints, enter s3 in the search box. 5. In the search results, do one of the following: For a Node.js function, choose s3-get-object. For a Python function, choose s3-get-object-python. 6. Choose Configure. 7. Under Basic information, do the following: a) For Function name, enter my-s3-function. b) For Execution role, choose Create a new role from AWS policy templates. c) For Role name, enter my-s3-function-role. 8. Under S3 trigger, choose the S3 bucket that you created previously. When you configure an S3 trigger using the Lambda console, the console modifies your function's resource-based policy to allow Amazon S3 to invoke the function. 9. Choose Create function. 10. Create mys3testevent test function to test the lambda function  https://docs.aws.amazon.com/lambda/latest/dg/with-s3-example.html 39 LAB 4 (OPTIONAL): KUBERNETES PRIMARY  Prerequisite  Create an IAM role, give AmazonEKSClusterPolicy and AmazonEKSServicePolicy  Create an IAM role, give AmazonEKS_CNI_policy and AmazonEKSWorkerNodePolicy  Install kubectl https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html  (Add kubectl.exe into the environment path)  Create VPCs for the cluster  aws eks update-kubeconfig --name mynginxcluster //update local config file  Create work nodes on EC2  Add work nodes to cluster  Create deployment yaml file and deploy it  Create service yaml file and deploy it  kubectl describe svc nginx  Copy the public IP and view the web application deployed  https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html 40 ASSIGNMENT 1. Create an Auto Scaling VM group using launch template 2. Attach a load balancer to the Auto Scaling group (e.g. Application LB) 3. Violate the scaling policy (terminate VM/stress CPU) to see how ASG scale out and scale in 4. Write a simple report with key steps and the screenshot of each step 5. Submit your homework via eLearn 6. Choose one project topic and list down the compute resources for it (no need to submit) 41