GCP ver1.4.pdf
Document Details
Uploaded by LovedEucalyptus
Full Transcript
1. REGIONS AND ZONES 14 REGIONS AND ZONES Imagine that your application is deployed in a data center in London What would be the challenges? Challenge 1 : Slow access for users from other parts of the world (high latency) Challenge 2 : What if the data center crashes? Your application goes down (low...
1. REGIONS AND ZONES 14 REGIONS AND ZONES Imagine that your application is deployed in a data center in London What would be the challenges? Challenge 1 : Slow access for users from other parts of the world (high latency) Challenge 2 : What if the data center crashes? Your application goes down (low availability) 15 MULTIPLE DATA CENTERS Let's add in one more data center in London What would be the challenges? Challenge 1 : Slow access for users from other parts of the world Challenge 2 (SOLVED) : What if one data center crashes? Your application is still available from the other data center Challenge 3 : What if entire region of London is unavailable? Your application goes down 16 MULTIPLE REGIONS Let's add a new region : Doha What would be the challenges? Challenge 1 (PARTLY SOLVED) : Slow access for users from other parts of the world You can solve this by adding deployments for your applications in other regions Challenge 2 (SOLVED) : What if one data center crashes? Your application is still live from the other data centers Challenge 3 (SOLVED) : What if entire region of London is unavailable? Your application is served from Doha 17 REGIONS Imagine setting up data centers in different regions around the world Would that be easy? (Solution) Google provides 20+ regions around the world (Expanding every year) Region: Specific geographical location to host your resources Advantages: High Availability Low Latency Global Footprint Adhere to government regulations ZONES How to achieve high availability in the same region (or geographic location)? Enter Zones Each Region has three or more zones Advantage of Zones: Increased availability and fault tolerance within same region (Remember) Zones in a region are connected through low-latency links REGIONS AND ZONES EXAMPLES New Regions and Zones are constantly added Region Code us-west1 europe-north1 asia-south1 Region Zones Zones List The Dalles, Oregon, North America 3 us-west1-a us-west1-b us-west1-c Hamina, Finland, Europe 3 europe-north1-a, europe-north1-b europe-north1-c Mumbai, India APAC 3 asia-south1-a, asia-south1-b asia-south1-c 2. COMPUTE ENGINE FUNDAMENTALS GOOGLE COMPUTE ENGINE (GCE) In corporate data centers, applications are deployed to physical servers Where do you deploy applications in the cloud? Rent virtual servers Virtual Machines - Virtual servers in GCP Google Compute Engine (GCE) - Provision & Manage Virtual Machines COMPUTE ENGINE - FEATURES Create and manage lifecycle of Virtual Machine (VM) instances Load balancing and auto scaling for multiple VM instances Attach storage (& network storage) to your VM instances Manage network connectivity and configuration for your VM instances COMPUTE ENGINE MACHINE FAMILY MACHINE FAMILY: A CURATED SET OF PROCESSOR AND HARDWARE CONFIGURATIONS OPTIMIZED FOR SPECIFIC WORKLOADS. WHEN YOU CREATE A VM, YOU CHOOSE A PREDEFINED OR CUSTOM MACHINE TYPE FROM YOUR PREFERRED MACHINE FAMILY. MACHINE SERIES: MACHINE FAMILIES ARE FURTHER CLASSIFIED BY SERIES AND GENERATION. FOR EXAMPLE, THE N1 SERIES WITHIN THE GENERAL-PURPOSE MACHINE FAMILY IS THE OLDER VERSION OF THE N2 SERIES. A HIGHER GENERATION OR SERIES NUMBER USUALLY INDICATES NEWER UNDERLYING CPU PLATFORMS OR TECHNOLOGIES. FOR EXAMPLE, THE M3 SERIES IS THE NEWER GENERATION OF THE M2 SERIES. MACHINE TYPE: EVERY MACHINE SERIES HAS PREDEFINED MACHINE TYPES THAT PROVIDE A SET OF RESOURCES FOR YOUR VM. IF A PREDEFINED MACHINE TYPE DOES NOT MEET YOUR NEEDS, YOU CAN ALSO CREATE A CUSTOM MACHINE FOR SOME MACHINE SERIES. COMPUTE ENGINE MACHINE TYPES * How much CPU, memory or disk do you want? Variety of machine types are available for each machine family Let's take an example : e2-standard-2: - e2 - Machine Type Family - standard - Type of workload - 2 - Number of CPUs * Memory, disk and networking capabilities increase along with vCPUs IMAGE What operating system and what software do you want on the instance? Type of Images: Public Images: Provided & maintained by Google or Open source communities or third party Vendors Custom Images: Created by you for your projects COMPUTE ENGINE : SETTING UP A WEB SERVER #! /bin/bash sudo su apt update apt -y install apache2 sudo service apache2 start sudo update-rc.d apache2 enable echo "Hello World" > /var/www/html/index.html echo "Hello world from $(hostname) $(hostname -I)" > /var/www/html/index.html Commands: sudo su - execute commands as a root user apt update - Update package index - pull the latest changes from the APT repositories apt -y install apache2 - Install apache2 web server sudo service apache2 start - Start apache2 web server echo "Hello World" > /var/www/html/index.html - Write to index.html $(hostname) - Get host name $(hostname -I) - Get host internal IP address BOOTSTRAPPING WITH STARTUP SCRIPT #!/bin/bash apt update apt -y install apache2 echo "Hello world from $(hostname) $(hostname -I)" > /var/www/html/index.html Bootstrapping: Install OS patches or software when an VM instance is launched. In VM, you can configure Startup script to bootstrap INSTANCE TEMPLATES Why do you need to specify all the VM instance details (Image, instance type etc) every time you launch an instance? How about creating a Instance template? Define machine type, image, labels, startup script and other properties Used to create VM instances and managed instance groups Provides a convenient way to create similar instances CANNOT be updated To make a change, copy an existing template and modify it (Optional) Image family can be specified (example - debian-9): Latest non-deprecated version of the family is used REDUCING LAUNCH TIME WITH CUSTOM IMAGE Installing OS patches and software at launch of VM instances increases boot up time How about creating a custom image with OS patches and software pre-installed? Can be created from an instance, a persistent disk, a snapshot, another image, or a file in Cloud Storage Can be shared across projects (Recommendation) Deprecate old images (& specify replacement image) (Recommendation) Hardening an Image - Customize images to your corporate security standards Prefer using Custom Image to Startup script 36 SUSTAINED USE DISCOUNTS Automatic discounts for running VM instances for significant portion of the billing month Example: If you use N1, N2 machine types for more than 25% of a month, you get a 20% to 50% discount on every incremental minute. Discount increases with usage (graph) No action required on your part! Applicable for instances created by Google Kubernetes Engine and Compute Engine RESTRICTION: Does NOT apply on certain machine types (example: E2 and A2) RESTRICTION: Does NOT apply to VMs created by App Engine flexible and Dataflow Source: https://cloud.google.com 37 COMMITTED USE DISCOUNTS FOR WORKLOADS WITH PREDICTABLE RESOURCE NEEDS COMMIT FOR 1 YEAR OR 3 YEARS UP TO 70% DISCOUNT BASED ON MACHINE TYPE AND GPUS APPLICABLE FOR INSTANCES CREATED BY GOOGLE KUBERNETES ENGINE AND COMPUTE ENGINE RESTRICTION: DOES NOT APPLY TO VMS CREATED BY APP ENGINE FLEXIBLE AND DATAFLOW PREEMPTIBLE VM Short-lived cheaper (upto 80%) compute instances Can be stopped by GCP any time (preempted) within 24 hours Instances get 30 second warning (to save anything they want to save) Use Preempt VM's if: Your applications are fault tolerant You are very cost sensitive Your workload is NOT immediate Example: Non immediate batch processing jobs RESTRICTIONS: NOT always available NO SLA and CANNOT be migrated to regular VMs NO Automatic Restarts Free Tier credits not applicable COMPUTE ENGINE: BILLING YOU ARE BILLED BY THE SECOND (AFTER A MINIMUM OF 1 MINUTE) YOU ARE NOT BILLED FOR COMPUTE WHEN A COMPUTE INSTANCE IS STOPPED o HOWEVER, YOU WILL BE BILLED FOR ANY STORAGE ATTACHED WITH IT! (RECOMMENDATION) ALWAYS CREATE BUDGET ALERTS AND MAKE USE OF BUDGET EXPORTS TO STAY ON TOP OF BILLING! WHAT ARE THE WAYS YOU CAN SAVE MONEY? o CHOOSE THE RIGHT MACHINE TYPE AND IMAGE FOR YOUR WORKLOAD o BE AWARE OF THE DISCOUNTS AVAILABLE: SUSTAINED USE DISCOUNTS COMMITTED USE DISCOUNTS DISCOUNTS FOR PREEMPTIBLE VM INSTANCES COMPUTE ENGINE FEATURES: CUSTOM MACHINE TYPES WHAT DO YOU DO WHEN PREDEFINED VM OPTIONS ARE NOT APPROPRIATE FOR YOUR WORKLOAD? o CREATE A MACHINE TYPE CUSTOMIZED TO YOUR NEEDS (A CUSTOM MACHINE TYPE) CUSTOM MACHINE TYPE: ADJUST VCPUS, MEMORY AND GPUS o CHOOSE BETWEEN E2, N2, OR N1 MACHINE TYPES o SUPPORTS A WIDE VARIETY OF OPERATING SYSTEMS: CENTOS, COREOS, DEBIAN, RED HAT, UBUNTU, WINDOWS.. ETC o BILLED PER VCPUS, MEMORY PROVISIONED TO EACH INSTANCE EXAMPLE HOURLY PRICE: $0.033174 / VCPU + $0.004446 / GB COMPUTE ENGINE : GPUS How do you accelerate math intensive and graphicsintensive workloads for AI/ML.. etc? Add a GPU to your virtual machine: o High performance for math intensive and graphics-intensive workloads o Higher Cost o (REMEMBER) Use images with GPU libraries (Deep Learning) installed OTHERWISE, GPU will not be used GPU restrictions: NOT supported on all machine types (For example, not supported on shared-core or memory-optimized machine types) Recommended Availability policy for GPUs Automatic restart - on VIRTUAL MACHINE - REMEMBER Associated with a project Machine type availability can vary from region to regions You can only change the machine type (adjust the number of vCPUs and memory) of a stopped instance You CANNOT change the machine type of a running instance VM's can be filtered by various properties Name, Zone, Machine Type, Internal/External IP, Network, Labels etc Instances are Zonal (Run in a specific zone (in a specific region)) Images are global (You can provide access to other projects - if needed) Instance templates are global (Unless you use zonal resources in your templates) Automatic Basic Monitoring is enabled Default Metrics: CPU utilization, Network Bytes (in/out), Disk Throughput/IOPS For Memory Utilization & Disk Space Utilization - Cloud Monitoring agent is needed 44 VIRTUAL MACHINE - BEST PRACTICES CHOOSE ZONE AND REGION BASED ON: o COST, REGULATIONS, AVAILABILITY NEEDS, LATENCY AND SPECIFIC HARDWARE NEEDS o DISTRIBUTE INSTANCES IN MULTIPLE ZONES AND REGIONS FOR HIGH AVAILABILITY CHOOSE RIGHT MACHINE TYPE FOR YOU NEEDS: o PLAY WITH THEM TO FIND OUT THE RIGHT MACHINE TYPE o USE GPUS FOR MATH AND GRAPHIC INTENSIVE APPLICATIONS RESERVE FOR "COMMITTED USE DISCOUNTS" FOR CONSTANT WORKLOADS USE PREEMPTIBLE INSTANCES FOR FAULT-TOLERANT, NON TIME CRITICAL WORKLOADS USE LABELS TO INDICATE ENVIRONMENT, TEAM, BUSINESS UNIT ETC 45 CLOUD LOAD BALANCING 71 CLOUD LOAD BALANCING Distributes user traffic across instances of an application in single region or multiple regions o Fully distributed, software defined managed service o Important Features: Health check - Route to healthy instances Recover from failures Auto Scaling Global load balancing with single anycast IP Also supports internal load balancing Enables: o High Availability o Auto Scaling o Resiliency HTTP VS HTTPS VS TCP VS TLS VS UDP Computers use protocols to communicate Multiple layers and multiple protocols Network Layer - Transfer bits and bytes Transport Layer- Are the bits and bytes transferred properly? Application Layer- Make REST API calls and Send Emails (Remember) Each layer makes use of the layers beneath it (Remember) Most applications talk at application layer. BUT some applications talk at transport layer directly (high performance). HTTP VS HTTPS VS TCP VS TLS VS UDP Network Layer: IP (Internet Protocol): Transfer bytes. Unreliable. Transport Layer: TCP (Transmission Control): Reliability > Performance TLS (Transport Layer Security): Secure TCP UDP (User Datagram Protocol): Performance > Reliability Application Layer: HTTP(Hypertext Transfer Protocol): Response Cycle HTTPS: Secure HTTP SMTP: Email Transfer Protocol and a lot of others... Stateless Request HTTP VS HTTPS VS TCP VS TLS VS UDP Applications typically communicate at application layer o Web apps/REST API(HTTP/HTTPS), Email Servers(SMTP), File Transfers(FTP) o All these applications use TCP/TLS at network layer(for reliability) HOWEVER applications needing high performance directly communicate at transport layer: o Gaming applications and live video streaming use UDP (sacrifice reliability for performance) CLOUD LOAD BALANCING - TERMINOLOGY Backend: Group of endpoints that receive traffic from a Google Cloud load balancer (e.g. instance group) Frontend: Specify an IP address, port and protocol. This IP address is the frontend IP for clients requests. For SSL, a certificate must be assigned Host and Path : (for HTTP(s) Load Balancing) – Defines rules redirecting the traffic to differenet backends: o based on path - in28minutes.com/a vs in28minutes.com/b o Based on Host - a.in28minutes.com vs b.in28minutes.com o Based on HTTP headers (Authorization header) and methods (POST, GET, etc) o etc.. LOAD BALANCING – SSL/TLS TERMINATION/OFFLOADING Client to Load Balancer: Over internet o HTTPS recommended Load Balancer to VM instance: Through Google internal network o HTTP is ok. HTTPS is preferred. SSL/TLS Termination/Offloading o Client to Load Balancer: HTTPS/TLS o Load Balancer to VM instance: HTTP/TCP APPLICATION LOAD BALANCERS APPLICATION LOAD BALANCERS ARE PROXY-BASED LAYER 7 LOAD BALANCERS ENABLE RUNNING AND SCALING YOUR SERVICES BEHIND AN ANYCAST IP ADDRESS. DISTRIBUTES HTTP AND HTTPS TRAFFIC TO BACKENDS HOSTED ON A VARIETY OF GOOGLE CLOUD PLATFORMS—SUCH AS COMPUTE ENGINE AND GOOGLE KUBERNETES ENGINE (GKE)— CAN DISTRIBUTE HTTP AND HTTPS TRAFFIC TO EXTERNAL BACKENDS OUTSIDE GOOGLE CLOUD. APPLICATION LOAD BALANCERS CAN BE DEPLOYED EXTERNALLY OR INTERNALLY DEPENDING ON WHETHER YOUR APPLICATION IS INTERNET-FACING OR INTERNAL: APPLICATION LOAD BALANCERS NETWORK LOAD BALANCERS NETWORK LOAD BALANCERS ARE LAYER 4 LOAD BALANCERS THAT CAN HANDLE TCP, UDP, OR OTHER IP PROTOCOL TRAFFIC. AVAILABLE AS EITHER PROXY LOAD BALANCERS PASSTHROUGH LOAD BALANCERS. NETWORK LOAD BALANCERS NETWORK LOAD BALANCER APPLICATION LOAD BALANCER CLOUD LOAD BALANCING - CHOOSING LOAD BALANCER https://cloud.google.com/load-balancing/images/choose-lb.svg 49 CLOUD LOAD BALANCING - FEATURES Type of Traffic Proxy or passthrough Destination Ports External HTTP(S) Global, External, HTTP or HTTPS Proxy HTTP on 80 or 8080 HTTPS on 443 Internal HTTP(S) Regional, Internal, HTTP or HTTPS Proxy HTTP on 80 or 8080 HTTPS on 443 SSL Proxy Global, External, TCP with SSL offload Proxy A big list TCP Proxy Global, External, TCP without SSL offload Proxy A big list External Network TCP/UDP Regional, External, TCP or UDP Pass-through any Internal TCP/UDP Regional, Internal, TCP or UDP Pass-through any Load Balancer LOAD BALANCER SCENARIOS Scenario Solution You want only healthy instances to receive traffic Configure health check You want high availability for your VM instances Create Multiple MIGs (managed instance group) for your VM instances in multiple regions. Load balance using a Load Balancer. You want to route requests to multiple microservices using the same load balancer Create individual MIGs and backends for each microservice. Create Host and path rules to redirect to specific microservice backend based on the path (/microservice-a, /microservice-b etc). You can route to a backend Cloud Storage bucket as well. You want to load balance Global external HTTPS traffic across backend instances, across multiple regions Choose External HTTP(S) Load Balancer You want SSL termination for Global non-HTTPS traffic with load balancing Choose SSL Proxy Load Balancer 51 GCP NETWORKING NEED FOR GOOGLE CLOUD VPC In a corporate network or an on-premises data center: Can anyone on the internet see the data exchange between the application and the database? No Can anyone from internet directly connect to your database? Typically NO. You need to connect to your corporate network and then access your applications or databases. Corporate network provides a secure internal network protecting your resources, data and communication from external users How do you do create your own private network in the cloud? Enter Virtual Private Cloud (VPC) GOOGLE CLOUD VPC (VIRTUAL PRIVATE CLOUD) YOUR OWN ISOLATED NETWORK IN GCP CLOUD NETWORK TRAFFIC WITHIN A VPC IS ISOLATED (NOT VISIBLE) FROM ALL OTHER GOOGLE CLOUD VPCS YOU CONTROL ALL THE TRAFFIC COMING IN AND GOING OUTSIDE A VPC (BEST PRACTICE) CREATE ALL YOUR GCP RESOURCES (COMPUTE, STORAGE, DATABASES ETC) WITHIN A VPC SECURE RESOURCES FROM UNAUTHORIZED ACCESS AND ENABLE SECURE COMMUNICATION BETWEEN YOUR CLOUD RESOURCES VPC IS A GLOBAL RESOURCE & CONTAINS SUBNETS IN ONE OR MOREREGION (REMEMBER) NOT TIED TO A REGION OR A ZONE. VPC RESOURCES CAN BE IN ANY REGION OR ZONE! NEED FOR VPC SUBNETS Different types of resources are created on cloud - databases, compute etc Each type of resource has its own access needs Load Balancers are accessible from internet (public resources) Databases or VM instances should NOT be accessible from internet ONLY applications within your network (VPC) should be able to access them(private resources) How do you separate public resources from private resources inside a VPC? Create separate Subnets! (Additional Reason) You want to distribute resources across multiple regions for high availability VPC SUBNETS (Solution) Create different subnets for public and private resources Resources in a public subnet CAN be accessed from internet Resources in a private subnet CANNOT be accessed from internet BUT resources in public subnet can talk to resources in private subnet Each Subnet is created in a region Example : VPC - demo-vpc => Subnets - region us-central1, europe-west1 or us-west1 or.. CREATING VPCS AND SUBNETS By default, every project has a default VPC You can create YOUR own VPCs: OPTION 1: Auto mode VPC network: Subnets are automatically created in each region Default VPC created automatically in the project uses auto mode! OPTION 2: Custom mode VPC network: No subnets are automatically created You have complete control over subnets and their IP ranges Recommended for Production Options when you create a subnet: Enable Private Google Access - Allows VM's to connect to Google API's using private IP's Enable FlowLogs - To troubleshoot any VPC related network issues CIDR (CLASSLESS INTER-DOMAIN ROUTING) BLOCKS Resources in a network use continuous IP addresses to make routing easy: Example: Resources inside a specific network can use IP addresses from 69.208.0.0 to 69.208.0.15 How do you express a range of addresses that resources in a network can have? CIDR block A CIDR block consists of a starting IP address(69.208.0.0) and a range(/28) Example: CIDR block 69.208.0.0/28 represents addresses from 69.208.0.0 to 69.208.0.15 - a total of 16 addresses Quick Tip: 69.208.0.0/28 indicates that the first 28 bits (out of 32) are fixed. Last 4 bits can change => 2 to the power 4 = 16 addresses CIDR EXAMPLES Exercise : How many addresses does 69.208.0.0/26 represent? 2 to the power (32-26 = 6) = 64 addresses from 69.208.0.0 to 69.208.0.63 Exercise : How many addresses does 69.208.0.0/30 represent? 2 to the power (32-30 = 2) = 4 addresses from 69.208.0.0 to 69.208.0.3 Exercise : What is the difference between 0.0.0.0/0 and 0.0.0.0/32? 0.0.0.0/0 represent all IP addresses. 0.0.0.0/32 represents just one IP address 0.0.0.0. RECOMMENDED CIDR BLOCKS - VPC SUBNETS Recommended CIDR Blocks Private IP addresses RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 Shared address space RFC 6598: 100.64.0.0/10 IETF protocol assignments RFC 6890: 192.0.0.0/24 Restricted Range Examples You CANNOT use these as CIDR for VPC Subnets Private Google Access-specific virtual IP addresses: 199.36.153.4/30, 199.36.153.8/30 Current (local) network RFC 1122: 0.0.0.0/8 Local host RFC 1122: 127.0.0.0/8 (REMEMBER) You CAN EXTEND the CIDR Block Range of a Subnet (Secondary CIDR Block) FIREWALL RULES CONFIGURE FIREWALL RULES TO CONTROL TRAFFIC GOING IN OR OUT OF THE NETWORK: STATEFUL EACH FIREWALL RULE HAS PRIORITY (0-65535) ASSIGNED TO IT 0 HAS HIGHEST PRIORITY. 65535 HAS LEAST PRIORITY DEFAULT IMPLIED RULE WITH LOWEST PRIORITY (65535) ALLOW ALL EGRESS DENY ALL INGRESS DEFAULT RULES CAN'T BE DELETED YOU CAN OVERRIDE DEFAULT RULES BY DEFINING NEW RULES WITH PRIORITY 0-65534 DEFAULT VPC HAS 4 ADDITIONAL RULES WITH PRIORITY 65534 ALLOW INCOMING TRAFFIC FROM VM INSTANCES IN SAME NETWORK (DEFAULT-ALLOWINTERNAL) ALLOW INCOMING TCP TRAFFIC ON PORT 22 (SSH) DEFAULT-ALLOW-SSH ALLOW INCOMING TCP TRAFFIC ON PORT 3389 (RDP) DEFAULT-ALLOW-RDP ALLOW INCOMING ICMP FROM ANY SOURCE ON THE NETWORK DEFAULT-ALLOW-ICMP FIREWALL RULES - INGRESS AND EGRESS RULES INGRESS RULES: INCOMING TRAffICC FROM OUTSIDE TO GCP TARGETS TARGET (DEFINES THE DESTINATION): ALL INSTANCES OR INSTANCES WITH TAG/SA SOURCE (DEFINES WHERE THE TRAffIC IS COMING FROM): CIDR OR ALL INSTANCES OR INSTANCES WITH TAG/SA EGRESS RULES: OUTGOING TRAffICC TO DESTINATION FROM GCP TARGETS TARGET (DEFINES THE SOURCE): ALL INSTANCES OR INSTANCES WITH TAG/SA DESTINATION: CIDR BLOCK ALONG WITH EACH RULE, YOU CAN ALSO DEFINE: PRIORITY - LOWER THE NUMBER, HIGHER THE PRIORITY ACTION ON MATCH - ALLOW OR DENY TRAffIC PROTOCOL - EX. TCP OR UDP OR ICMP PORT - WHICH PORT? ENFORCEMENT STATUS - ENABLE OR DISABLE THE RULE SHARED VPC SCENARIO: YOUR ORGANIZATION HAS MULTIPLE PROJECTS. YOU WANT RESOURCES IN DIFFERENT PROJECTS TO TALK TO EACH OTHER? HOW TO ALLOW RESOURCES IN DIFFERENT PROJECTS TO TALK WITH INTERNAL IPS SECURELY AND EFFICIENTLY? SOLUTION IS SHARED VPC CREATED AT ORGANIZATION OR SHARED FOLDER LEVEL (ACCESS NEEDED: SHARED VPC ADMIN) ALLOWS VPC NETWORK TO BE SHARED BETWEEN PROJECTS IN SAME ORGANIZATION SHARED VPC CONTAINS ONE HOST PROJECT AND MULTIPLE SERVICE PROJECTS: HOST PROJECT - CONTAINS SHARED VPC NETWORK SERVICE PROJECTS - ATTACHED TO HOST PROJECTS HELPS YOU ACHIEVE SEPARATION OF CONCERNS: NETWORK ADMINISTRATORS RESPONSIBLE FOR HOST PROJECTS AND RESOURCE USERS USE SERVICE PROJECT VPC PEERING Scenario: How to connect VPC networks across different organizations? VPC Peering Networks in same project, different projects and across projects in different organizations can be peered All communication happens using internal IP addresses Highly efficient because all communication happens inside Google network Highly secure because not accessible from Internet No data transfer charges for data transfer between services (REMEMBER) Network administration is NOT changed: Admin of one VPC do not get the role automatically in a peered network HYBRID CLOUD CLOUD VPN CLOUD VPN - CONNECT ON-PREMISE NETWORK TO THE GCP NETWORK IMPLEMENTED USING IPSEC VPN TUNNEL TRAffICC THROUGH INTERNET (PUBLIC) TRAffICC ENCRYPTED USING INTERNET KEY EXCHANGE PROTOCOL TWO TYPES OF CLOUD VPN SOLUTIONS: HA VPN (SLA OF 99.99% SERVICE AVAILABILITY WITH TWO EXTERNAL IP ADDRESSES) ONLY DYNAMIC ROUTING (BGP) SUPPORTED CLASSIC VPN (SLA OF 99.9% SERVICE AVAILABILITY, A SINGLE EXTERNAL IP ADDRESS) SUPPORTS STATIC ROUTING (POLICY-BASED, ROUTE-BASED) AND DYNAMIC ROUTING USING BGP CLOUD INTERCONNECT High speed physical connection between on-premise and VPC networks: Highly available and high throughput Two types of connections possible Dedicated Interconnect - 10 Gbps or 100 Gpbs configurations Partner Interconnect - 50 Mbps to 10 Gbps configurations Data exchange happens through a private network: Communicate using VPC network's internal IP addresses from on-premise network Reduces egress costs As public internet is NOT used (Feature) Supported Google API's and services can be privately accessed from on-premise Use only for high bandwidth needs: For low bandwidth, Cloud VPN is recommended DIRECT PEERING Connect customer network to google network using network peering Direct path from on-premises network to Google services Not a GCP Service Lower level network connection outside of GCP NOT RECOMMENDED: Use Cloud Interconnect and Cloud VPN IDENTITY AND ACESS MANAGEMENT IAM WHAT IS IAM Google Identity and Access Management is a web service that gives cloud administrators the authority to decide who can take a particular action on a particular resource. In simple words, IAM lets one decide who (Identity) has what role(Access) to which resource. HOW IAM WORKS WITH IAM, YOU MANAGE ACCESS CONTROL BY DEFINING WHO (IDENTITY) HAS WHAT ACCESS (ROLE) FOR WHICH RESOURCE. FOR EXAMPLE, COMPUTE ENGINE VIRTUAL MACHINE INSTANCES, GOOGLE KUBERNETES ENGINE (GKE) CLUSTERS, AND CLOUD STORAGE BUCKETS ARE ALL GOOGLE CLOUD RESOURCES. THE ORGANIZATIONS, FOLDERS, AND PROJECTS THAT YOU USE TO ORGANIZE YOUR RESOURCES ARE ALSO RESOURCES. IN IAM, PERMISSION TO ACCESS A RESOURCE ISN'T GRANTED DIRECTLY TO THE END USER. INSTEAD, PERMISSIONS ARE GROUPED INTO ROLES, AND ROLES ARE GRANTED TO AUTHENTICATED PRINCIPALS. (IN THE PAST, IAM OFTEN REFERRED TO PRINCIPALS AS MEMBERS. SOME APIS STILL USE THIS TERM.) AN ALLOW POLICY, ALSO KNOWN AS AN IAM POLICY, DEFINES AND ENFORCES WHAT ROLES ARE GRANTED TO WHICH PRINCIPALS. EACH ALLOW POLICY IS ATTACHED TO A RESOURCE. WHEN AN AUTHENTICATED PRINCIPAL ATTEMPTS TO ACCESS A RESOURCE, IAM CHECKS THE RESOURCE'S ALLOW POLICY TO DETERMINE WHETHER THE ACTION IS PERMITTED. PARTS OF ACCESS MANAGEMENT PRINCIPAL. A PRINCIPAL CAN BE A GOOGLE ACCOUNT (FOR END USERS), A SERVICE ACCOUNT (FOR APPLICATIONS AND COMPUTE WORKLOADS), A GOOGLE GROUP, OR A GOOGLE WORKSPACE ACCOUNT OR CLOUD IDENTITY DOMAIN THAT CAN ACCESS A RESOURCE. EACH PRINCIPAL HAS ITS OWN IDENTIFIER, WHICH IS TYPICALLY AN EMAIL ADDRESS. ROLE. A ROLE IS A COLLECTION OF PERMISSIONS. PERMISSIONS DETERMINE WHAT OPERATIONS ARE ALLOWED ON A RESOURCE. WHEN YOU GRANT A ROLE TO A PRINCIPAL, YOU GRANT ALL THE PERMISSIONS THAT THE ROLE CONTAINS. POLICY. THE ALLOW POLICY IS A COLLECTION OF ROLE BINDINGS THAT BIND ONE OR MORE PRINCIPALS TO INDIVIDUAL ROLES. WHEN YOU WANT TO DEFINE WHO (PRINCIPAL) HAS WHAT TYPE OF ACCESS (ROLE) ON A RESOURCE, YOU CREATE AN ALLOW POLICY AND ATTACH IT TO THE RESOURCE. In the diagram, for example, the allow policy binds principals, such as user@exam ple.com, to roles, such as the App Engine Admin role (roles/appengin e.appAdmin). If the allow policy is attached to a project, the principals gain the specified roles within the project. CONCEPTS RELATED TO IDENTITY IN IAM, YOU GRANT ACCESS TO PRINCIPALS. PRINCIPALS CAN BE OF THE FOLLOWING TYPES: GOOGLE ACCOUNT SERVICE ACCOUNT GOOGLE GROUP GOOGLE WORKSPACE ACCOUNT CLOUD IDENTITY DOMAIN ALL AUTHENTICATED USERS ALL USERS GOOGLE ACCOUNT A GOOGLE ACCOUNT REPRESENTS A DEVELOPER, AN ADMINISTRATOR, OR ANY OTHER PERSON WHO INTERACTS WITH GOOGLE CLOUD. ANY EMAIL ADDRESS THAT'S ASSOCIATED WITH A GOOGLE ACCOUNT CAN BE AN IDENTITY, INCLUDING GMAIL.COM OR OTHER DOMAINS. NEW USERS CAN SIGN UP FOR A GOOGLE ACCOUNT BY GOING TO THE GOOGLE ACCOUNT SIGNUP PAGE. SERVICE ACCOUNT A SERVICE ACCOUNT IS AN ACCOUNT FOR AN APPLICATION OR COMPUTE WORKLOAD INSTEAD OF AN INDIVIDUAL END USER. WHEN YOU RUN CODE THAT'S HOSTED ON GOOGLE CLOUD, THE CODE RUNS AS THE ACCOUNT YOU SPECIFY. YOU CAN CREATE AS MANY SERVICE ACCOUNTS AS NEEDED TO REPRESENT THE DIFFERENT LOGICAL COMPONENTS OF YOUR APPLICATION. GOOGLE GROUP A GOOGLE GROUP IS A NAMED COLLECTION OF GOOGLE ACCOUNTS AND SERVICE ACCOUNTS. EVERY GOOGLE GROUP HAS A UNIQUE EMAIL ADDRESS THAT'S ASSOCIATED WITH THE GROUP. YOU CAN FIND THE EMAIL ADDRESS THAT'S ASSOCIATED WITH A GOOGLE GROUP BY CLICKING ABOUT ON THE HOMEPAGE OF ANY GOOGLE GROUP. GOOGLE GROUPS ARE A CONVENIENT WAY TO APPLY ACCESS CONTROLS TO A COLLECTION OF USERS. YOU CAN GRANT AND CHANGE ACCESS CONTROLS FOR A WHOLE GROUP AT ONCE INSTEAD OF GRANTING OR CHANGING ACCESS CONTROLS ONE AT A TIME FOR INDIVIDUAL USERS OR SERVICE ACCOUNTS. YOU CAN ALSO EASILY ADD PRINCIPALS TO AND REMOVE PRINCIPALS FROM A GOOGLE GROUP INSTEAD OF UPDATING AN ALLOW POLICY TO ADD OR REMOVE USERS. GOOGLE GROUPS DON'T HAVE LOGIN CREDENTIALS, AND YOU CANNOT USE GOOGLE GROUPS TO ESTABLISH IDENTITY TO MAKE A REQUEST TO ACCESS A RESOURCE. GOOGLE WORKSPACE ACCOUNT A GOOGLE WORKSPACE ACCOUNT REPRESENTS A VIRTUAL GROUP OF ALL OF THE GOOGLE ACCOUNTS THAT IT CONTAINS. GOOGLE WORKSPACE ACCOUNTS ARE ASSOCIATED WITH YOUR ORGANIZATION'S INTERNET DOMAIN NAME, SUCH AS EXAMPLE.COM. WHEN YOU CREATE A GOOGLE ACCOUNT FOR A NEW USER, SUCH AS [email protected], THAT GOOGLE ACCOUNT IS ADDED TO THE VIRTUAL GROUP FOR YOUR GOOGLE WORKSPACE ACCOUNT. LIKE GOOGLE GROUPS, GOOGLE WORKSPACE ACCOUNTS CANNOT BE USED TO ESTABLISH IDENTITY, BUT THEY ENABLE CONVENIENT PERMISSION MANAGEMENT. CLOUD IDENTITY DOMAIN A CLOUD IDENTITY DOMAIN IS LIKE A GOOGLE WORKSPACE ACCOUNT, BECAUSE IT REPRESENTS A VIRTUAL GROUP OF ALL GOOGLE ACCOUNTS IN AN ORGANIZATION. HOWEVER, CLOUD IDENTITY DOMAIN USERS DON'T HAVE ACCESS TO GOOGLE WORKSPACE APPLICATIONS AND FEATURES. ALL AUTHENTICATED USERS THE VALUE ALLAUTHENTICATEDUSERS IS A SPECIAL IDENTIFIER THAT REPRESENTS ALL SERVICE ACCOUNTS AND ALL USERS ON THE INTERNET WHO HAVE AUTHENTICATED WITH A GOOGLE ACCOUNT. THIS IDENTIFIER INCLUDES ACCOUNTS THAT AREN'T CONNECTED TO A GOOGLE WORKSPACE ACCOUNT OR CLOUD IDENTITY DOMAIN, SUCH AS PERSONAL GMAIL ACCOUNTS. USERS WHO AREN'T AUTHENTICATED, SUCH AS ANONYMOUS VISITORS, AREN'T INCLUDED. ALL USERS THE VALUE ALLUSERS IS A SPECIAL IDENTIFIER THAT REPRESENTS ANYONE WHO IS ON THE INTERNET, INCLUDING AUTHENTICATED AND UNAUTHENTICATED USERS. SOME RESOURCE TYPES DO NOT SUPPORT THIS PRINCIPAL TYPE. RESOURCES IF A USER NEEDS ACCESS TO A SPECIFIC GOOGLE CLOUD RESOURCE, YOU CAN GRANT THE USER A ROLE FOR THAT RESOURCE. SOME EXAMPLES OF RESOURCES ARE PROJECTS, COMPUTE ENGINE INSTANCES, AND CLOUD STORAGE BUCKETS. SOME SERVICES SUPPORT GRANTING IAM PERMISSIONS AT A GRANULARITY FINER THAN THE PROJECT LEVEL. FOR EXAMPLE, YOU CAN GRANT THE STORAGE ADMIN ROLE (ROLES/STORAGE.ADMIN) TO A USER FOR A PARTICULAR CLOUD STORAGE BUCKET, OR YOU CAN GRANT THE COMPUTE INSTANCE ADMIN ROLE (ROLES/COMPUTE.INSTANCEADMIN) TO A USER FOR A SPECIFIC COMPUTE ENGINE INSTANCE. IN OTHER CASES, YOU CAN GRANT IAM PERMISSIONS AT THE PROJECT LEVEL. THE PERMISSIONS ARE THEN INHERITED BY ALL RESOURCES WITHIN THAT PROJECT. FOR EXAMPLE, TO GRANT ACCESS TO ALL CLOUD STORAGE BUCKETS IN A PROJECT, GRANT ACCESS TO THE PROJECT INSTEAD OF EACH INDIVIDUAL BUCKET. OR TO GRANT ACCESS TO ALL COMPUTE ENGINE INSTANCES IN A PROJECT, GRANT ACCESS TO THE PROJECT RATHER THAN EACH INDIVIDUAL INSTANCE. PERMISSIONS PERMISSIONS DETERMINE WHAT OPERATIONS ARE ALLOWED ON A RESOURCE. IN THE IAM WORLD, PERMISSIONS ARE REPRESENTED IN THE FORM OF SERVICE.RESOURCE.VERB, FOR EXAMPLE, PUBSUB.SUBSCRIPTIONS.CONSUME. PERMISSIONS OFTEN CORRESPOND ONE-TO-ONE WITH REST API METHODS. THAT IS, EACH GOOGLE CLOUD SERVICE HAS AN ASSOCIATED SET OF PERMISSIONS FOR EACH REST API METHOD THAT IT EXPOSES. THE CALLER OF THAT METHOD NEEDS THOSE PERMISSIONS TO CALL THAT METHOD. FOR EXAMPLE, IF YOU USE PUB/SUB, AND YOU NEED TO CALL THE TOPICS.PUBLISH()METHOD, YOU MUST HAVE THE PUBSUB.TOPICS.PUBLISH PERMISSION FOR THAT TOPIC. YOU DON'T GRANT PERMISSIONS TO USERS DIRECTLY. INSTEAD, YOU IDENTIFY ROLES THAT CONTAIN THE APPROPRIATE PERMISSIONS, AND THEN GRANT THOSE ROLES TO THE USER. ROLES A ROLE IS A COLLECTION OF PERMISSIONS. YOU CANNOT GRANT A PERMISSION TO THE USER DIRECTLY. INSTEAD, YOU GRANT THEM A ROLE. WHEN YOU GRANT A ROLE TO A USER, YOU GRANT THEM ALL THE PERMISSIONS THAT THE ROLE CONTAINS. TYPES OF ROLES IN IAM: BASIC ROLES: ROLES HISTORICALLY AVAILABLE IN THE GOOGLE CLOUD CONSOLE. THESE ROLES ARE OWNER, EDITOR, AND VIEWER. CAUTION: BASIC ROLES INCLUDE THOUSANDS OF PERMISSIONS ACROSS ALL GOOGLE CLOUD SERVICES. IN PRODUCTION ENVIRONMENTS, DO NOT GRANT BASIC ROLES UNLESS THERE IS NO ALTERNATIVE. INSTEAD, GRANT THE MOST LIMITED PREDEFINED ROLES OR CUSTOM ROLES THAT MEET YOUR NEEDS. PREDEFINED ROLES: ROLES THAT GIVE FINER-GRAINED ACCESS CONTROL THAN THE BASIC ROLES. FOR EXAMPLE, THE PREDEFINED ROLE PUB/SUB PUBLISHER (ROLES/PUBSUB.PUBLISHER) PROVIDES ACCESS TO ONLY PUBLISH MESSAGES TO A PUB/SUB TOPIC. CUSTOM ROLES: ROLES THAT YOU CREATE TO TAILOR PERMISSIONS TO THE NEEDS OF YOUR ORGANIZATION WHEN PREDEFINED ROLES DON'T MEET YOUR NEEDS. 1. PRIMITIVE ROLES ALSO CALLED BASIC ROLES, THESE ROLES WERE THERE SINCE BEFORE THE INTRODUCTION OF IAM. THEY OFFER A FIXED, COARSE-GRAINED LEVEL OF ACCESS TO GCP RESOURCES. PRIMITIVE ROLES ARE APPLICABLE ACROSS ALL GOOGLE CLOUD SERVICES IN A PROJECT. THERE ARE THREE PRIMITIVE ROLES: OWNER EDITOR VIEWER 2. PREDEFINED ROLES PREDEFINED ROLES WERE INTRODUCED WITH IAM TO GRANT MORE FINE-GRAINED ACCESS CONTROL AS COMPARED TO THE BASIC ROLES. THESE ROLES ARE ONLY APPLICABLE TO A PARTICULAR SERVICE IN A PROJECT. ANY GIVEN PREDEFINED ROLE CAN BE GRANTED TO A RESOURCE TYPE OR A TYPE ABOVE IT. MULTIPLE ROLES CAN BE ASSIGNED TO A SINGLE USER AS WELL. THERE ARE THOUSANDS OF PREDEFINED ROLES IN GOOGLE IAM. 3. CUSTOM ROLES ONE OF THE MORE INTERESTING PARTS OF IAM IS THE ABILITY TO CREATE YOUR OWN CUSTOM ROLES. THE USER-CREATED ROLE CAN HAVE ONE OR MORE PERMISSIONS ASSOCIATED WITH IT. THEY CAN BE CREATED BY COMBINING EXISTING CLOUD IAM PERMISSIONS. CUSTOM ROLES ARE FULLY USER-MANAGED AND HAVE NO INVOLVEMENT FROM GOOGLE’S SIDE. FOR THE CREATION AND MANAGEMENT OF CUSTOM ROLES, GCP PROVIDES A UI AND AN API. THE ONLY PRE-REQUISITE FOR CREATING A CUSTOM ROLE IS THAT ONE MUST HAVE AN ADMIN ROLE THEMSELF. IT CAN BE EITHER ROLES/IAM.ROLEADMIN OR ROLES/IAM.ORGANIZATION.ROLEADMIN, DEPENDING ON ALLOW POLICY YOU CAN GRANT ROLES TO USERS BY CREATING AN ALLOW POLICY AN ALLOW POLICY IS A COLLECTION OF STATEMENTS THAT DEFINE WHO HAS WHAT TYPE OF ACCESS. AN ALLOW POLICY IS ATTACHED TO A RESOURCE AND IS USED TO ENFORCE ACCESS CONTROL WHENEVER THAT RESOURCE IS ACCESSED. RESOURCE HIERARCHY GOOGLE CLOUD RESOURCES ARE ORGANIZED HIERARCHICALLY: THE ORGANIZATION IS THE ROOT NODE IN THE HIERARCHY. FOLDERS ARE CHILDREN OF THE ORGANIZATION, OR OF ANOTHER FOLDER. PROJECTS ARE CHILDREN OF THE ORGANIZATION, OR OF A FOLDER. RESOURCES FOR EACH SERVICE ARE DESCENDANTS OF PROJECTS. EACH RESOURCE HAS EXACTLY ONE PARENT. MANAGED COMPUTE SERVICES 81 MANAGED COMPUTE SERVICES You should understand some terminology used with cloud services: IaaS (Infrastructure as a Service) PaaS (Platform as a Service) FaaS (Function as a Service) CaaS (Container as a Service) Serverless 108 IAAS (INFRASTRUCTURE AS A SERVICE) Use only infrastructure from cloud provider Example: Using VM to deploy your applications or databases You are responsible for: Application Code and Runtime Configuring load balancing Auto scaling OS upgrades and patches Availability etc.. ( and a lot of things!) 109 PAAS (PLATFORM AS A SERVICE) Use a platform provided by cloud Cloud provider is responsible for: OS (incl. upgrades and patches) Application Runtime Auto scaling, Availability & Load balancing etc.. User is responsible for: Configuration (of Application and Services) Application code (if needed) Varieties: CAAS (Container as a Service): Containers instead of Apps FAAS (Function as a Service): Functions instead of Apps Databases - Relational & NoSQL (Amazon RDS, Google Cloud SQL, Azure SQL Database etc), Queues, AI, ML, Operations etc! 110 MICROSERVICES Enterprises are heading towards microservices architectures -Build small focused microservices -Flexibility to innovate and build applications in different programming languages But deployments become complex How can we have one way of deploying Go, Java, Python or JavaScript.. microservices? containers! CONTAINERS - DOCKER Create Docker images for each microservice Docker image has all needs of a microservice: Application Runtime (JDK or Python or NodeJS) Application code and Dependencies Runs the same way on any infrastructure: Your local machine Corporate data center Cloud Advantages Docker containers are light weight Compared to Virtual Machines as they do not have a Guest OS Docker provides isolation for containers Docker is cloud neutral 112 CONTAINER ORCHESTRATION Requirement : I want 10 instances of Microservice A container, 15 instances of Microservice B container and.... Typical Features: Auto Scaling - Scale containers based on demand Service Discovery - Help microservices find one another Load Balancer - Distribute load among multiple instances of a microservice Self Healing - Do health checks and replace failing instances Zero Downtime Deployments - Release new versions without downtime 113 SERVERLESS WHAT DO WE THINK ABOUT WHEN WE DEVELOP AN APPLICATION? o WHERE TO DEPLOY? WHAT KIND OF SERVER? WHAT OS? o HOW DO WE TAKE CARE OF SCALING AND AVAILABILITY OF THE APPLICATION? WHAT IF YOU DON'T NEED TO WORRY ABOUT SERVERS AND FOCUS ON YOUR CODE? o SOLUTION IS SERVERLESS o REMEMBER: SERVERLESS DOES NOT MEAN "NO SERVERS" SERVERLESS FOR ME: o YOU DON'T WORRY ABOUT INFRASTRUCTURE (ZERO VISIBILITY INTO INFRASTRUCTURE) FLEXIBLE SCALING AND AUTOMATED HIGH AVAILABILITY o MOST IMPORTANT: PAY FOR USE IDEALLY ZERO REQUESTS => ZERO COST YOU FOCUS ON CODE AND THE CLOUD MANAGED SERVICE TAKES CARE OF ALL THAT IS NEEDED TO SCALE YOUR CODE TO SERVE MILLIONS OF REQUESTS! o AND YOU PAY FOR REQUESTS AND NOT SERVERS! SERVERLESS SERVERLESS - IMPORTANT FEATURES: o 1: ZERO WORRY ABOUT INFRASTRUCTURE, SCALING AND AVAILABILITY o 2: ZERO INVOCATIONS => ZERO COST (CAN YOU SCALE DOWN TO ZERO INSTANCES?) o 3: PAY FOR INVOCATIONS AND NOT FOR INSTANCES (OR NODES OR SERVERS) SERVERLESS LEVEL 1: FEATURES (1 + 2) SERVERLESS LEVEL 2: FEATURES (1 + 2 + 3) WHEN I REFER TO SERVERLESS, I'M REFERRING TO LEVEL 2 HOWEVER CLOUD PROVIDERS INCLUDE MANAGED SERVICES AT LEVEL 1 AND LEVEL 2: o LEVEL 1: GOOGLE APP ENGINE (GOOGLE CALLS IT "APP ENGINE IS A FULLY MANAGED, SERVERLESS PLATFORM"), AWS FARGATE (AWS CALLS IT "SERVERLESS COMPUTE ENGINE FOR CONTAINERS") SCALE DOWN TO ZERO INSTANCES WHEN THERE IS NO LOAD, BUT YOU PAY FOR NUMBER (AND TYPE) OF INSTANCES RUNNING! o LEVEL 2: GOOGLE FUNCTIONS, AWS LAMBDA, AZURE FUNCTIONS ETC YOU PAY FOR INVOCATIONS MANAGED COMPUTE SERVICES Service Details Category Compute Engine High-performance and general purpose VMs that scale globally IaaS Google Kubernetes Engine Orchestrate containerized microservices on Kubernetes Needs advanced cluster configuration and monitoring CaaS App Engine Build highly scalable applications on a fully managed platform using open and familiar languages and tools Cloud Functions Build event driven applications using simple, single-purpose functions FaaS, Serverless Cloud Run Develop and deploy highly scalable containerized applications. Does NOT need a cluster! CaaS (Serverless) PaaS (CaaS, Serverless) APP ENGINE APP ENGINE Simplest way to deploy and scale your applications in GCP o Provides end-to-end application management Supports: o Go, Java,.NET, Node.js, PHP, Python, Ruby using pre-configured runtimes o Use custom run-time and write code in any language o Connect to variety of Google Cloud storage products (Cloud SQL etc) No usage charges - Pay for resources provisioned Features: o Automatic load balancing & Auto scaling o Managed platform updates & Application health monitoring Application versioning o Traffic splitting COMPUTE ENGINE VS APP ENGINE Compute Engine IAAS MORE Flexibility MORE Responsibility Choosing Image Installing Software Choosing Hardware Fine grained Access/Permissions (Certificates/Firewalls) Availability etc App Engine PaaS Serverless LESSER Responsibility LOWER Flexibility APP ENGINE ENVIRONMENTS Standard: Applications run in language specific sandboxes Complete isolation from OS/Disk/Other Apps V1: Java, Python, PHP, Go (OLD Versions) ONLY for Python and PHP runtimes: Restricted network Access Only white-listed extensions and libraries are allowed No Restrictions for Java and Go runtimes V2: Java, Python, PHP, Node.js, Ruby, Go (NEWER Versions) Full Network Access and No restrictions on Language Extensions Flexible - Application instances run within Docker containers Makes use of Compute Engine virtual machines Support ANY runtime (with built-in support for Python, Java, Node.js, Go, Ruby, PHP, or.NET) Provides access to background processes and local disks APP ENGINE - APPLICATION COMPONENT HIERARCHY Application: One App per Project Service(s): Multiple Microservices or App components You can have multiple services in a single application Each Service can have different settings Earlier called Modules Version(s): Each version associated with code and configuration Each Version can run in one or more instances Multiple versions can co-exist Options to rollback and split traffic APP ENGINE - COMPARISON Feature Standard Flexible Pricing Factors Instance hours vCPU, Memory & Persistent Disks Scaling Manual, Basic, Automatic Manual, Automatic Scaling to zero Yes No. Minimum one instance Instance startup time Seconds Minutes Rapid Scaling Yes No Max. request timeout 1 to 10 minutes 60 minutes Local disk Mostly(except for Python, PHP). Can write to /tmp. Yes. Ephemeral. New Disk on startup. SSH for debugging No Yes APP ENGINE - SCALING INSTANCES Automatic - Automatically scale instances based on the load: Recommended for Continuously Running Workloads Auto scale based on: Target CPU Utilization - Configure a CPU usage threshold. Target Throughput Utilization - Configure a throughput threshold Max Concurrent Requests - Configure max concurrent requests an instance can receive Configure Max Instances and Min Instances Basic - Instances are created as and when requests are received: Recommended for Adhoc Workloads Instances are shutdown if ZERO requests Tries to keep costs low High latency is possible NOT supported by App Engine Flexible Environment Configure Max Instances and Idle Timeout Manual - Configure specific number of instances to run: Adjust number of instances manually over time APP ENGINE - REMEMBER AppEngine is Regional (services deployed across zones) You CANNOT change an Application's region Good option for simple microservices (multiple services) Use Standard v2 when you are using supported languages Use Flexible if you are building containerized apps Be aware - ATLEAST one container is always running when using Flexible: Go for Standard if you want to be able to scale down the number of instances to zero when there is NO load Use a combination of resident and dynamic instances Resident Instances: Run continuously Dynamic Instances: Added based on load Use all dynamic instances if you are cost sensitive If you are not very cost sensitive, keep a set of resident instances running always APP ENGINE - SCENARIOS Scenario Solution I want to create two Google App Engine Apps in the same project Not possible. You can only have one App Engine App per project. However you can have multiple services and multiple version for each service. I want to create two Google App Engine Services inside the same App Yup. You can create multiple services under the same app. Each service can have multiple versions as well. I want to move my Google App Engine App to a different region App Engine App is region specific. You CANNOT move it to different region. Create a new project and create new app engine app in the new region. Perform Canary deployments Deploy v2 without shifting traffic (gcloud app deploy --nopromote) Shift some traffic to V2 (gcloud app services set-traffic s1 --splits v1=0.9,v2=0.1) STORAGE STORAGE TYPES – BLOCK STORAGE & FILE STORAGE What is the type of storage of your hard disk? Block Storage You've created a file share to share a set of files with your colleagues in a enterprise. What type of storage are you using? File Storage 127 BLOCK STORAGE Use case: Harddisks attached to your computers Typically, ONE Block Storage device can be connected to ONE virtual server (EXCEPTIONS) You can attach read only block devices with multiple virtual servers and certain cloud providers are exploring multi-writer disks as well! HOWEVER, you can connect multiple different block storage devices to one virtual server Used as: Direct-attached storage (DAS) - Similar to a hard disk Storage Area Network (SAN) - High-speed network connecting a pool of storage devices Used by Databases - Oracle and Microsoft SQL Server FILE STORAGE Media workflows need huge shared storage for supporting processes like video editing Enterprise users need a quick way to share files in a secure and organized way These file shares are shared by several virtual servers 129 GCP - BLOCK STORAGE AND FILE STORAGE BLOCK STORAGE: PERSISTENT DISKS: NETWORK BLOCK STORAGE ZONAL: DATA REPLICATED IN ONE ZONE REGIONAL: DATA REPLICATED IN MULTIPLE ZONE LOCAL SSDS: LOCAL BLOCK STORAGE FILE STORAGE: FILESTORE: HIGH PERFORMANCE FILE STORAGE GCP - BLOCK STORAGE TWO POPULAR TYPES OF BLOCK STORAGE CAN BE ATTACHED TO VM INSTANCES: LOCAL SSDS PERSISTENT DISKS LOCAL SSDS ARE PHYSICALLY ATTACHED TO THE HOST OF THE VM INSTANCE TEMPORARY DATA LIFECYCLE TIED TO VM INSTANCE PERSISTENT DISKS ARE NETWORK STORAGE MORE DURABLE LIFECYCLE NOT TIED TO VM INSTANCE LOCAL SSDS Physically attached to the host of VM instance: Provide very high (IOPS) and very low latency (BUT) Ephemeral storage - Temporary data (Data persists only until instance is running) Enable live migration for data to survive maintenance events Data automatically encrypted HOWEVER, you CANNOT configure encryption keys! Lifecycle tied to VM instance ONLY some machine types support Local SSDs Supports SCSI and NVMe interfaces Remember: Choose NVMe-enabled and multi-queue SCSI images for best performance Larger Local SSDs (more storage), More vCPUs (attached to VM) => Even Better Performance 132 LOCAL SSDS - ADVANTAGES AND DISADVANTAGES ADVANTAGES VERY FAST I/O (~ 10-100X COMPARED TO PDS) HIGHER THROUGHPUT AND LOWER LATENCY IDEAL FOR USE CASES NEEDING HIGH IOPS WHILE STORING TEMPORARY INFORMATION EXAMPLES: CACHES, TEMPORARY DATA, SCRATCH FILES ETC DISADVANTAGES EPHEMERAL STORAGE LOWER DURABILITY, LOWER AVAILABILITY, LOWER FLEXIBILITY COMPARED TO PDS YOU CANNOT DETACH AND ATTACH IT TO ANOTHER VM INSTANCE 133 PERSISTENT DISKS (PD) Network block storage attached to your VM instance Provisioned capacity Very Flexible: Increase size when you need it - when attached to VM instance Performance scales with size For higher performance, resize or add more PDs Independent lifecycle from VM instance Attach/Detach from one VM instance to another Options: Regional and Zonal Zonal PDs replicated in single zone. Regional PDs replicated in 2 zones in same Region. Typically Regional PDs are 2X the cost of Zonal PDs Use case : Run your custom database 134 PERSISTENT DISKS VS LOCAL SSDS Feature Persistent Disks Local SSDs Attachment to VM instance As a network drive Physically attached Lifecycle Separate from VM instance Tied with VM instance I/O Speed Lower (network latency) 10-100X of PDs Snapshots Supported Not Supported Use case Permanent storage Ephemeral storage PERSISTENT DISKS - STANDARD VS BALANCED VS SSD Feature Standard Balanced SSD Underlying Storage Hard Disk Drive Solid State Drive Solid State Drive Referred to as pd-standard pd-balanced pd-ssd Performance - Sequential IOPS (Big Data/Batch) Good Good Very Good Performance - Random IOPS (Transactional Apps) Bad Good Very Good Cost Cheapest In Between Expensive Use cases Big Data (cost efficient) Balance between cost and performance High Performance PERSISTENT DISKS - SNAPSHOTS Take point-in-time snapshots of your Persistent Disks You can also schedule snapshots (configure a schedule): You can also auto-delete snapshots after X days Snapshots can be Multi-regional and Regional You can share snapshots across projects You can create new disks and instances from snapshots Snapshots are incremental: Deleting a snapshot only deletes data which is NOT needed by other snapshots Keep similar data together on a Persistent Disk: Separate your operating system, volatile data and permanent data Attach multiple disks if needed This helps to better organize your snapshots and images PERSISTENT DISKS – SNAPSHOTS - RECOMMENDATIONS AVOID TAKING SNAPSHOTS MORE OFTEN THAN ONCE AN HOUR DISK VOLUME IS AVAILABLE FOR USE BUT SNAPSHOTS REDUCE PERFORMANCE (RECOMMENDED) SCHEDULE SNAPSHOTS DURING Off-PEAK HOURS CREATING SNAPSHOTS FROM DISK IS FASTER THAN CREATING FROM IMAGES: BUT CREATING DISKS FROM IMAGE IS FASTER THAN CREATING FROM SNAPSHOTS (RECOMMENDED) IF YOU ARE REPEATEDLY CREATING DISKS FROM A SNAPSHOT: CREATE AN IMAGE FROM SNAPSHOT AND USE THE IMAGE TO CREATE DISKS SNAPSHOTS ARE INCREMENTAL: BUT YOU DON'T LOSE DATA BY DELETING OLDER SNAPSHOTS DELETING A SNAPSHOT ONLY DELETES DATA WHICH IS NOT NEEDED BY OTHER SNAPSHOTS (RECOMMENDED) DO NOT HESITATE TO DELETE UNNECESSARY SNAPSHOTS PLAYING WITH MACHINE IMAGES (REMEMBER) MACHINE IMAGE IS DIffERENT FROM IMAGE MULTIPLE DISKS CAN BE ATTACHED WITH A VM: ONE BOOT DISK (YOUR OS RUNS FROM BOOT DISK) MULTIPLE DATA DISKS AN IMAGE IS CREATED FROM THE BOOT PERSISTENT DISK HOWEVER, A MACHINE IMAGE IS CREATED FROM A VM INSTANCE: MACHINE IMAGE CONTAINS EVERYTHING YOU NEED TO CREATE A VM INSTANCE: CONFIGURATION METADAT A PERMISSI ONS DATA FROM ONE OR MORE DISKS RECOMMENDED FOR DISK BACKUPS, INSTANCE CLONING AND REPLICATION 139 COMPARISON https://cloud.google.com/compute/docs/machine-images STORAGE - SCENARIOS - PERSISTENT DISKS Scenario Solution You want to improve performance of Persistent Disks (PD) Increase size of PD or Add more PDs. Increase vCPUs in your VM. You want to increase durability of Persistent Disks (PD) Go for Regional PDs (2X cost but replicated in 2 zones) You want to take hourly backup of Persistent Disks (PD) for disaster recovery Schedule hourly snapshots! You want to delete old snapshots created by scheduled snapshots Configure it as part of your snapshot scheduling! 141 CLOUD FILESTORE Shared cloud file storage: Supports NFSv3 protocol Provisioned Capacity Suitable for high performance workloads: Up to 320 TB with throughput of 16 GB/s and 480K IOPS Supports HDD (general purpose) and SSD (performance-critical workloads) Use cases : file share, media workflows and content management REVIEW – GLOBAL, REGIONAL AND ZONAL RESOURCES Global Images Snapshots Instance templates (Unless you use zonal resources in your templates) Regional Regional managed instance groups Regional persistent disks Zonal Zonal managed instance groups Instances Persistent disks You can attach a disk only to instances in the same zone as the disk STORAGE - SCENARIOS Scenario Solution You want Very High IOPS but your data can be lost without a problem Local SSDs You want to create a high perfomance file sharing system in GCP which can be attached with multiple VMs Filestore You want to backup your VM configuration along with all its attached Persistent Disks Create a Machine Image You want to make it easy to launch VMs with hardened OS and customized software Create a Custom Image OBJECT STORAGE - CLOUD STORAGE 145 CLOUD STORAGE Most popular, very flexible & inexpensive storage service Serverless: Autoscaling and infinite scale Store large objects using a key-value approach: Treats entire object as a unit (Partial updates not allowed) Recommended when you operate on entire object most of the time Access Control at Object level Also called Object Storage Provides REST API to access and modify objects Also provides CLI (gsutil) & Client Libraries (C++, C#, Java, Node.js, PHP, Python & Ruby) Store all file types - text, binary, backup & archives: Media files and archives, Application packages and logs Backups of your databases or storage devices Staging data during on-premise to cloud database migration CLOUD STORAGE - OBJECTS AND BUCKETS Objects are stored in buckets Bucket names are globally unique Bucket names are used as part of object URLs => Can contain ONLY lower case letters, numbers, hyphens, underscores and periods. 3-63 characters max. Can't start with goog prefix or should not contain google (even misspelled) Unlimited objects in a bucket Each bucket is associated with a project Each object is identified by a unique key Key is unique in a bucket Max object size is 5 TB BUT you can store unlimited number of such objects 147 CLOUD STORAGE – STORAGE CLASSES - INTRODUCTION Different kinds of data can be stored in Cloud Storage Media files and archives Application packages and logs Backups of your databases or storage devices Long term archives Huge variations in access patterns Can I pay a cheaper price for objects I access less frequently? Storage classes help to optimize your costs based on your access needs Designed for durability of 99.999999999%(11 9’s) CLOUD STORAGE - STORAGE CLASSES - COMPARISON Name Minimum Storage duration Typical Monthly availability Use case Standard STANDARD None > 99.99% in multi region and dual region, 99.99% in regions Frequently used data/Short period of time Nearline storage NEARLINE 30 days 99.95% in multi region and dual region, 99.9% in regions Read or modify once a month on average Coldline storage COLDLINE 90 days 99.95% in multi region and dual region, 99.9% in regions Read or modify at most once a quarter Archive storage ARCHIVE 365 days 99.95% in multi region and dual region, 99.9% in regions Less than once a year Storage Class g 3, i FEATURES ACROSS STORAGE CLASSES High durability (99.999999999% annual durability) Low latency (first byte typically in tens of milliseconds) Unlimited storage Autoscaling (No configuration needed) NO minimum object size Same APIs across storage classes Committed SLA is 99.95% for multi region and 99.9% for single region for Standard, Nearline and Coldline storage classes No committed SLA for Archive storage CLOUD STORAGE – UPLOADING AND DOWNLOADING OBJECTS Option Recommended for Scenarios Simple Upload Small files (that can be re uploaded in case of failures) + NO object metadata Multipart upload Small files (that can be re uploaded in case of failures) + object metadata Resumable upload Larger files. RECOMMENDED for most usecases (even for small files - costs one additional HTTP request) Streaming transfers Upload an object of unknown size Parallel composite uploads File divided up to 32 chunks and uploaded in parallel. Significantly faster if network and disk speed are not limiting factors. Simple download Downloading objects to a destination Streaming download Downloading data to a process Sliced object download Slice and download large objects OBJECT VERSIONING Prevents accidental deletion & provides history Enabled at bucket level Can be turned on/off at any time Live version is the latest version If you delete live object, it becomes noncurrent object version If you delete noncurrent object version, it is deleted Older versions are uniquely identified by (object key + a generation number) Reduce costs by deleting older (noncurrent) versions! OBJECT LIFECYCLE MANAGEMENT FILES ARE FREQUENTLY ACCESSED WHEN THEY ARE CREATED GENERALLY USAGE REDUCES WITH TIME HOW DO YOU SAVE COSTS BY MOVING FILES AUTOMATICALLY BETWEEN STORAGE CLASSES? SOLUTION: OBJECT LIFECYCLE MANAGEMENT IDENTIFY OBJECTS USING CONDITIONS BASED ON: AGE, CREATEDBEFORE, ISLIVE, MATCHESSTORAGECLASS, NUMBEROFNEWERVERSIONS ETC SET MULTIPLE CONDITIONS: ALL CONDITIONS MUST BE SATISFIED FOR ACTION TO HAPPEN TWO KINDS OF ACTIONS: SETSTORAGECLASS ACTIONS (CHANGE FROM ONE STORAGE CLASS TO ANOTHER) DELETION ACTIONS (DELETE OBJECTS) ALLOWED TRANSITIONS: (STANDARD OR MULTI-REGIONAL OR REGIONAL) TO (NEARLINE OR COLDLINE OR ARCHIVE) NEARLINE TO (COLDLINE OR ARCHIVE) COLDLINE TO ARCHIVE - - Y es 6 ·. & S Z CLOUD STORAGE - ENCRYPTION Cloud Storage always encrypts data on the server side! Configure Server-side encryption: Encryption performed by Cloud Storage Google-managed encryption key - Default (No configuration required) Customer-managed encryption keys - Created using Cloud Key Management Service (KMS). Managed by customer in KMS. Cloud Storage Service Account should have access to keys in KMS for encrypting and decrypting using the Customer-Managed encryption key (OPTIONAL) Client-side encryption - Encryption performed by customer before upload GCP does NOT know about the keys used CLOUD STORAGE - SCENARIOS Scenario Just How do you speed up large uploads (example: 100 GB) to Cloud Storage? You want to permanently store application logs for regulatory reasons. You don't expect to access them at all. Log files stored in Cloud storage. You expect to access them once in quarter.. How do you change storage class of an existing bucket in Cloud Storage? DESCRIPTION USE PARALELCOMPOSITE UPLOADS(FILE ISBROKEN IN TO SMALL CHUNKS AND UPLOADED) CLOUD STORAGE - ARCHIVE COLD LINE STEP 1: CHANGE DEFAULT STORAGE CLASS OF THE BUCKET. STEP 2: UPDATE THE STORAGE CLASS OF THE OBJECTS IN THE BUCKET. 181