On this Thanksgiving Eve in the US, it is easy to recount the things for which I am grateful: my family, my friends, my health, etc. Monday will be 6 years since I exited from my service in the Marine Corps. At that time I was not sure I would even stay in tech as a career (law school still seems like a good backup plan). I am incredibly grateful and humbled by my career and the trajectory it has taken in recent years. A substantial part of this has been involvement in the tech community, especially the VMware community. I’m far from the only person that has built a career on the back of the VMware community. I am thankful for the guidance and inspiration I have received over the past six years.
It is imperative for any file system to be highly scalable, performant, and fault tolerant. Otherwise…why would you even bother to store data there? But realistically, achieving fault tolerance is done through data redundancy. On the flipside, the cost of redundancy is increased storage overhead. There are two possible encoding schemes for fault tolerance: triple mirroring (RF3) and erasure coding. To ensure the Scale Data Distributed Filesystem (SDFS, codenamed “Atlas”) is fault tolerant while increasing capacity and maintaining higher performance, Rubrik uses a schema called erasure coding.
As a part of its native replication, MongoDB maintains multiple copies of data in a construct called a replica set.
So, what is a replica set? A replica set in MongoDB is a group of mongod (primary daemon process for the MongoDB system) process that maintains the same data set. Put simply, it is a group of MongoDB servers operating in a primary / secondary failover fashion. Replica sets provide redundancy and high availability.
What is Sharding?
A server’s capacity can be challenged by database systems with large data sets or high throughput applications. For example, high query rates can consume the CPU capacity of the server; likewise working set sizes larger than a system’s RAM stress the IO capacity of disks.
It’s that time of summer — VMworld US is only a few days away! Yet again I am making the trek to Las Vegas for the festivities. I wanted to highlight the sessions where I will be presenting so that you have the opportunity to either schedule and come heckle or remind yourself to watch later. I will be hanging around the vBrownBag area of VMvillage or the Rubrik booth when not presenting; come say hello!
Part of me feels like it flew by but then I remember the hours spent reviewing all the designs (*ahem* Adam) and then it feels like it took an eternity to get through. Admittedly, Virtual Design Master was probably one of the coolest community driven events in which I have participated. If you are unfamiliar with Virtual Design Master, I strongly encourage you to check out the site and catch up with the five seasons.Read More »
Job interviews are tough. It’s the equivalent of both parties deciding whether they want to get married during the first date. So, imagine my surprise when Thom Greene asked me to conduct a mock interview with him in preparation for his job hunt. Thom was game enough to even allow me to record it as a vBrownBag session.Read More »
vBrownBag EMEA is in the midst of recording sessions that cover the VCAP6-DCV Deploy (3V0-622) exam. If you are interested in presenting one of the exam objective, see the Call for Presenters post here.
Objective 2.2 – Map Service Dependencies
Skills and Abilities
- Evaluate dependencies for infrastructure and application services that will be included in a vSphere design.
- Create Entity Relationship Diagrams that map service relationships and dependencies.
- Analyze interfaces to be used with new and existing business processes.
- Determine service dependencies for logical components.
- Include service dependencies in a vSphere 6.x Logical Design.
- Analyze services to identify upstream and downstream service dependencies.
- Navigate logical components and their interdependencies and make decisions based upon all service relationships.
- Graham’s blog post on Objective 2.2.
- Don Ward’s post called “VMware Application Dependencies and Entity Relationship Diagrams”
Without further ado, the podcast recording can be found here:
Nutanix does not want to be known for simply hyper-converged infrastructure. That was made very clear during Nutanix’s .NEXT conference in Washington DC two weeks ago. As Trevor Pott said in a recent article from The Register, “if all you’ve got to sell is HCI, then your company is already dead.” Nutanix is choosing to evolve rather than die.Read More »
This year I am honored to be one of the Virtual Design Master (vDM) judges. If you are unfamiliar with vDM, it is a technology driven reality competition that showcases virtualization community member and their talents as architects. Some competitors are seasoned architect while others are just beginning their design journey. To find out more information, please click here. One of the things that I, along with the other judges, noticed is that many of the contestants did not correctly document conceptual, logical, and physical design.
The best non-IT example that I have seen of this concept the following image:
The way I always describe and diagram design methodology is using the following image:
I will continue to refer to both images as we move forward in this post.
During the assess phase, the architect reaches out to the business’ key stakeholders for the project and explore what each need and want to get out of the project. The job is to identify key constraints and the business requirements that should be met for the design, deploy, and validation phases to be successful.
The assessment phase typically coincides with building the conceptual model of a design. Effectively, the conceptual model categorizes the assessment findings into requirements, constraints, assumptions, and risks categories.
- technicloud.com should create art.
- The art should be durable and able to withstand years of appreciation.
- Art should be able to be appreciated by millions around the world.
- Art cannot be a monolithic installation piece taking up an entire floor of the museum.
- Art must not be so bourgeoisie that it cannot be appreciated with an untrained eye.
- Art must not be paint-by-numbers.
- Lead IT architect at technicloud.com has no prior experience creating art.
- Mitigation – will require art classes to be taken at local community college.
- Lead IT architect is left-handed which may lead to smearing of art.
- Mitigation – IT architect will retrain as ambidextrous.
- Art classes at community college make artists.
- Museum will provide security as to ensure art appreciators do not damage artwork.
As you read through the requirements and constraints, the idea of how the design should look should be getting clearer and clearer. More risks and assumptions will be added as design decisions are made and the impact is analyzed. Notice that the conceptual model was made up entirely of words? Emphasis on “concept” in the word “conceptual”!
Once the conceptual model is built out, the architect moves into the logical design phrase (which indicated by the arrows pointing backwards in Figure 2, demonstrating dependence on conceptual). Logical design is where the architect begins making decisions but at a higher level.
Logical art work design decisions –
- Art will be a painting.
- The painting will be of a person.
- The person will be a woman.
For those who are having a hard time following with the art example, a tech example would be:
An example of what a logical diagram may look something like this:
Notice that these are ‘higher’ level decisions and diagrams. We’re not quite to filling in the details yet when working on logical design. However, note that these design decisions should map back to the conceptual model.
Once the logical design has been mapped out, architect moves to physical design where hardware and software vendors are chosen and configuration specifications are made. Simply put, this is the phase where the details are determined.
Physical art work design decisions –
- The painting will be a half-length portrait.
- The medium will be oil on a poplar panel.
- The woman will have brown hair.
Once again, if you hate the Mona Lisa then the IT design decision example would be:
- XYZ vendor and model of storage array will be purchased.
- Storage policy based management will be used to place VMs on the correct storage tier.
- Tier-1 LUNs will be replicated hourly.
These are physical design decisions, which directly correlate and extend the logical design decisions with more information. But, again, at the end of the day, this should all tie back to meeting the business requirements.
An example of a physical design would be something like:
Notice that in this diagram, we’re starting to see more details: vendor, model, how things are connected, etc. Remember that physical should expand on logical design decisions and fill in the blanks. At the end of the day, both logical and physical design decisions should map back to meeting the business requirements set forth in the conceptual model (as evidenced by Figure 2).
Being able to quickly and easily distinguish takes time and practice. I am hoping this clarifies some of the mystery and confusion surrounding this idea. Looking forward to seeing more vDM submissions next week.