VMware vSphere 5.x Datacenter Design Cookbook
Description
Book DescriptionA practical guide packed with step-by-step recipes to design a virtual datacenter using VMware 5.x. This book is a guide for anyone interested in designing virtualized datacenters using VMware vSphere 5.x and the supporting components. Current administrators of VMware vSphere environments will find this book useful when interested in becoming a vSphere Architect or are interested in learning more about the virtual datacenter design process. Knowledge of vSphere installation, configuration, and administration is a prerequisite.What you will learn
Identify key factors related to a vSphere design and apply them to every step of the design process
Create a vSphere conceptual design by identifying technical and business requirements
Design for performance, availability, recoverability, manageability, and security
Map the logical resource design into the physical vSphere design
Create professional vSphere design documentation to ensure a successful implementation of the vSphere design
Who this book is for
More details
Other editions
Additional editions
Person
Hersey Cartwright has worked in the technology industry since 1996 in many roles, from help desk support to IT management. He first started working with VMware technologies in 2006. He is currently a Solutions Engineer for VMware, where he designs, sells, and supports VMware software-defined datacenter products in enterprise environments within the healthcare industry. He has experience working with a wide variety of server, storage, and network platforms.
Content
FIM Synchronization Service (FIM Sync)
FIM Synchronization Service is the oldest member of the FIM family. Anyone who has worked with MIIS back in 2003 will feel quite at home with it. Visually, the management tools look the same.
FIM Synchronization Service can actually work by itself, without any other component of FIM 2010 R2 being present. You will then basically get the same functionality as MIIS had, back in 2003.
FIM Synchronization Service is the heart of FIM, which pumps the data around, causing information about identities to flow from one system to another.
Let's look at the pieces that make up the FIM Synchronization Service:
As you can see, there are lots of acronyms and concepts that need a little explaining.
On the right-hand side of FIM Synchronization Service, we have Metaverse (MV). Metaverse is used to collect all the information about all the identities managed by FIM.
On the other side, we have Connected Data Source (CDS). Connected Data Source is the database, directory, and file, among others, that the synchronization service imports information regarding the managed identities from, and/or exports this information to.
To talk to different kinds of Connected Data Sources, FIM Synchronization Service uses adapters that are called Management Agents (MA). In FIM 2010 R2, we will start to use the term Connectors, instead. But, as the user interface in FIM Synchronization Manager still uses the term Management Agent, I will use that term throughout this book.
The Management Agent stores a representation of the objects in the CDS, in its Connector Space (CS). When stored in the Connector Space, we refer to the objects as holograms. If we were to look into this a little deeper, we would find that the holograms (objects) are actually stored in multiple instances so that the Management Agent can keep a track of the changes to the objects in the Connector Space.
In order to synchronize information from/to different Connected Data Sources, we connect the objects in the Connector Space with the corresponding object in the Metaverse. By collecting information from all Connected Data Sources, the synchronization engine aggregates the information about the object from all the Connected Data Sources into the Metaverse object. This way, the Metaverse will only contain one representation of the object (for example, a user).
To describe the data flow within the synchronization service, let's look at the previous diagram and follow a typical scenario.
The scenario is this-we want information in our Human Resource (HR) system to govern how users appear in Active Directory (AD) and in our e-mail system.
- Import users from HR: The bottom CDS could be our HR system. We configure a Management Agent to import users from HR to the corresponding CS.
- Projection to Metaverse: As there is no corresponding user in the MV that we can connect to, we tell the MA to create a new object in the MV. The process of creating new objects in the MV is called Projection. To transfer information from the HR CS to the MV, we configure Inbound Synchronization Rules.
- Import and join users from AD: The middle CDS could be Active Directory (AD). We configure a Management Agent to import users from AD. Because there are objects in the MV, we can now tell the Management Agent to try to match the user objects from AD to the objects in the MV. Connecting existing objects in a Connector Space, to an existing object in the Metaverse, is called Joining. In order for the synchronization service to know which objects to connect, some kind of unique information must be present, to get a one-to-one mapping between the object in the CS and the object in the Metaverse.
- Synchronize information from HR to AD: Once the Metaverse object has a connector to both the HR CS and the AD CS, we can move information from the HR CS to the AD CS. We can, for example, use the employee status information in the HR system to modify the userAccountControl attribute of the AD account. In order to modify the AD CS object, we configure an Outbound Synchronization rule that will tell the synchronization service how to update the CS object based on the information in the MV object. Synchronizing, however, does not modify the user object in AD; it only modifies the hologram representation of the user in the AD Connector Space.
- Export information to AD: In order to actually change any information in a Connected Data Source, we need to tell the MA to export the changes. During export, the MA updates the objects in the CDS with the changes it has made to the hologram in the Connector Space.
- Provision users to the e-mail system: The top CDS could be our e-mail system. As users are not present in this system, we would like the synchronization service to create new objects in the CS for the e-mail system. The process of creating new objects in a Connector Space is called Provisioning.
Projection, Joining, and Provisioning all create a connector between the Metaverse object and the Connector Space object, making it possible to synchronize identity information between different Connected Data Sources.
A key concept to understand here, is that you do not configure synchronization between Connected Data Sources or between Connector Spaces. You synchronize between each Connector Space and Metaverse. Looking at the previous example, you can see that when information flows from HR to AD, you configure the following:
- HR MA to Import data to the HR CS
- Inbound synchronization from the HR CS to the MV
- Outbound synchronization from the MV to the AD CS
- AD MA to Export the data to AD
Management Agents
Management Agents , or Connectors as some people call them, are the entities that enable FIM to talk to different kinds of data sources. Basically, you can say that FIM can talk to any type of data source, but it only has built-in Management Agents for some. If the data source is really old, you might even have to use the extensibility platform and write your own Management Agent or buy a Management Agent from a third-party supplier. At http://aka.ms/FIMPartnerMA, you can find a list of Management Agents supplied by Microsoft Partners.
For a complete list of Management Agents built in and available from Microsoft, please look at http://aka.ms/FIMMA.
With R2, a new Management Agent for Extensible Connectivity 2.0 (ECMA 2.0) is released, introducing new ways of making custom Management Agents. I suppose that we will see updated versions of most third party Management Agents as soon as they are migrated to the new ECMA 2.0 platform. Microsoft will also ship new Management Agents using the new ECMA 2.0 platform.
Writing your own MA is one way of solving problems communicating with odd data sources. But, as I will discuss further in Chapter 11, Customizing Data Transformation, there might be other solutions to the problem that will require less coding.
Non-declarative vs. declarative synchronization
If you are using FIM Synchronization Service the old way, like we did in MIIS or ILM 2007, it is called non-declarative synchronization. I usually call that classic synchronization and will also use that term in this book. If we use the FIM Service logic to control it all, it is called declarative synchronization.
As classic synchronization usually involves writing code, and declarative does not; you will also find references calling declarative synchronization codeless.
In fact, it was quite possible, in some scenarios, to have codeless synchronization-even in the old MIIS or ILM 2007-using classic synchronization. The fact also remains that there are very few FIM 2010 R2 implementations that are indeed code free. In some cases you might even mix the two. This could be due either to migration from MIIS/ILM 2007 to FIM 2010 R2 or to the decision that it is cheaper/quicker/easier to solve a particular problem using classic synchronization.
The solutions I will describe in this book will be based on declarative synchronization, rather than the old-fashioned, classic ones. In Chapter 11, Customizing Data Transformations, I will show some examples in which classic synchronization is the best way to solve some problems.
Password synchronization
Let me first state that I am not a fan of using password synchronization. I believe that this should be the last resort to achieve some kind of Single Sign On (SSO). Instead of implementing password synchronization, I try to make my customers look at other ways, such as...
