Question : You work for a company named ABC.com. The company has a main office in New York and branch offices in several countries including UK, Spain, Germany, India and Japan. Your role as Cloud Administrator includes the management of the company's public and private cloud infrastructure. Separate Active Directory domains exist for the offices in Europe, India and Japan. The domains are synchronized to separate Azure Active Directories (Azure AD's) in separate Azure subscriptions. Company developers have created an application that will be used by all users in the company. You plan to publish the application to Azure AD as a SaaS (Software as a Service) application. You need to ensure that users in all offices can access the application. Which of the following actions should you perform? 1. Provision the application as a Single-tenant application. 2. Provision the application as a Multi-tenant application. 3. Provision the application as a native client application. 4. Configure an Affinity Group.
Correct Answer : 2 Explanation: Single Tenant vs. Multiple Tenant : One of the first architectural decisions that the team at Tailspin had to make about how the Surveys application could best support multiple subscribers was whether it should be a single-tenant or multi-tenant application. Figure 1 shows the difference between these approaches at a high-level. The single-tenant model has a separate physical instance of the application for each subscriber, while the multi-tenant model has a single physical instance of the application shared by many subscribers. It's important to note that the multi-tenant model still offers separate views of the application's data to its users. In the Surveys application, Client B must not be able to see or modify Client A's surveys or data. Tailspin, as the owner of the application, will have full access to all the data stored in the application.
In Windows Azure, the distinction between the multi-tenant model and the single-tenant model is not as straightforward as that shown in Figure 1 because an application in Windows Azure can consist of many elements, each of which can be single tenanted or multiple tenanted. For example, if an application has a user interface (UI) element, a services element, and a storage element, Selecting a Single-Tenant or Multi-Tenant Architecture This section introduces some of the criteria that an architect would consider when deciding on a single-tenant or multi-tenant design. The guide revisits many of these topics in more detail, and with specific reference to Tailspin and the Surveys application, in later chapters. The relative importance of the different criteria will vary for different application scenarios. This chapter focuses on application architecture, management, and financial considerations. Chapter 3, "Choosing a Multi-Tenant Data Architecture," explores the topics you must consider when choosing a suitable data architecture for a multi-tenant application. Architectural Considerations : The architectural requirements of your application will influence your choice of a single-tenant or multi-tenant architecture. The focus of this guide is on building a multi-tenant application using Windows Azure cloud services: web and worker roles. However, the architectural considerations addressed in this chapter, and many of the design decisions that Tailspin faced during the implementation of the Surveys application discussed in subsequent chapters, are equally relevant to other hosting choices for your multi-tenant application. For example, if you decide to build your multi-tenant application using Windows Azure Web Sites or to deploy it to Windows Azure Virtual Machines you will face many of the same challenges that Tailspin faced building the Surveys application for deployment to Windows Azure Cloud Services. For a detailed discussion of the Infrastructure as a Service (IaaS) approach offered by Windows Azure Virtual Machines, you should read Chapter 2, "Getting to the Cloud," in the guide "Moving Applications to the Cloud." Chapter 3, "Moving to Windows Azure Cloud Services," in that guide discusses using Windows Azure Web Sites to host your application in the cloud. Application Stability : A multi-tenant application is more vulnerable to instance failure than a single-tenant application. If a single-tenant instance fails, only the user of that instance is affected. If the multi-tenant instance fails, all users are affected. However, Windows Azure can help to mitigate this risk by enabling you to deploy multiple, identical instances of the Windows Azure roles that make up your application (this is really a multi-tenant, multi-instance model). Windows Azure load balances requests across those role instances, and you must design your application so that it functions correctly when you deploy multiple instances. For example, if your application uses session state you must make sure that each web role instance can access the state for any user. In addition, the tasks that a worker role performs must function correctly when Windows Azure can select any instance of the role to handle a particular task. Windows Azure monitors your role instances and automatically restarts any that have failed. For the Windows Azure SLA to apply to your application, you must have at least two instances of each role type running. For more information, see "Service Level Agreements." Windows Azure can throttle access to resources, making them temporarily unavailable. Typically, this happens when there is high contention for a resource. Your Windows Azure application should detect when it is being throttled, and take appropriate action such as retrying the operation after a short delay. Making the Application Scalable : The scalability of an application running on Windows Azure depends largely on being able to deploy multiple instances of your web and worker roles, while being able to access the same data from those instances. Both single-tenant and multi-tenant applications use this feature to scale out when they run on Windows Azure. Windows Azure also offers various instance sizes that enable you to scale up or scale down individual instances.
Question : You work for a company named ABC.com. Your role as Cloud Administrator includes the management of the company's public and private cloud infrastructure. You have applications, virtual machines and databases hosted on Windows Azure. One application hosted in Azure is named CorpApp. The application is business critical and is used by all company users. The application uses a database backend. The database is configured as a Microsoft Azure SQL Database database named CorpAppDB1. The company is concerned about a natural disaster affecting the data center that hosts the database. You want to configure active geo-replication to ensure that in the event of a natural disaster, you can bring the database online in another location. You need to determine if the current service tier and performance level supports active georeplication. Which of the following service tiers and performance combinations supports active georeplication? A. Basic B. Standard/S0 C. Standard/S1 D. Standard/S2 E. Premium/P1 F. Premium/P2 G. Premium/P3 1. A,B,C 2. C,D,E 3. E,F,G 4. A,C,G 5. A,C,E
Correct Answer : 3 Explanation: Premium: Designed for high transactional volume, supporting a large number of concurrent users and requiring the highest level of business continuity capabilities. Examples are databases supporting mission critical applications. How to Select a Service Tier and Performance Level
It is quick and easy to change between service tiers or performance levels. Changing service tiers and performance levels is an online operation - you can use the database throughout the operation. Take advantage of this flexibility to make cost effective decisions for your Azure SQL Database. For a new database that is in development, start with the Basic service tier. By monitoring your application performance, you can then work towards the optimum service tier and performance level. In addition, if you have an application that has a fluctuating workload that is predictable, you can move between performance levels that matches the peaks and low points. A good example of such an application would be one that has workload peaks typically at the end of the month. Regular Azure storage has a certain IOPS limit for each virtual disk: 500 IOPS for a disk attached to a standard-tier virtual machine and 300 IOPS for a disk attached to a basic-tier virtual machine. You can verify this information in "Virtual Machine and Cloud Service Sizes for Azure." The key detail here is that this IOPS number is a maximum; the actual IOPS your disk receives will vary depending on other factors, such as other workloads on the host and storage. The IOPS number is a maximum rather than a predictable, expected number of IOPS.
Premium Azure storage features various tiers of disks with different IOPS values. However, these numbers aren't just maximums but are expected levels of performance. This means you can expect to see those levels of performance, which provides the predictability of performance that some workloads need. P10: 128GB, 500 IOPS with 100MB/sec throughput P20: 512GB, 2300 IOPS with 150MB/sec throughput P30: 1024GB, 5000 IOPS with 200MB/sec throughput
Question : Your role of Systems Administrator at ABC.com includes the management of the company's private and public clouds. The private clouds are hosted in a data center at the company's headquarters. The private clouds are hosted on Windows Server 2012 R2 Hyper-V servers managed by System Center Virtual Machine Manager 2012 R2 (VMM). You want to implement Microsoft Azure Site Recovery to use Azure as a backup site for the datacenter. You create a site recovery vault and select the "Between an on-premises Hyper-V site and Microsoft Azure" option. Which of the following actions is the next step in configuring Azure Site Recovery?
1. Download and install the Microsoft Azure Site Recovery Provider. 2. Configure network mappings. 3. Download the Microsoft Azure Recovery Services Agent. 4. Generate a vault key. 5. Set up protection for VMM clouds.
Correct Answer : 4 Explanation: Azure Site Recovery contributes to your business continuity and disaster recovery (BCDR) strategy by orchestrating replication, failover and recovery of virtual machines in a number of deployment scenarios. For a full list of deployment scenarios see Azure Site Recovery overview.
This scenario guide describes how to deploy Site Recovery to orchestrate and automate protection for workloads running on virtual machines on Hyper-V host servers that are located in VMM private clouds. In this scenario virtual machines are replicated from a primary VMM site to a secondary VMM site using Hyper-V Replica.
The guide includes prerequisites for the scenario and shows you how to set up a Site Recovery vault, get the Azure Site Recovery Provider installed on source and target VMM servers, register the servers in the vault, configure protection settings for VMM clouds that will be applied to all protected virtual machines, and then enable protection for those virtual machines. Finish up by testing the failover to make sure everything's working as expected.
Generate a registration key in the vault. After you download the Azure Site Recovery Provider and install it on the VMM server, you'll use this key to register the VMM server in the vault.