Getting my hands on VMware Photon Platform 1.2 (Part 1)

I have been trying to self-learn VMware Photon Platform 1.2 from online documentation and from Cormac Hogan’s blog postings. Cormac has done an excellent job in hand holding beginners like me in introducing to the platform (Thanks Cormac). What I have here is to share some details on the way I built the same on my Intel NUC. This is by no means a step-by-step installation guide (will do one later) but something that can be used as a reference document to some extent, if you intend to build it locally on your own server from scratch.

1) My physical setup is simple (in my opinion). I use Intel NUC running VMware ESXi 6.0. I connect it with my MacbookPro with a crossover cable back-to-back. I define a dedicated network between the two. I then built the entire Photon platform 1.2 on my NUC, accessing it from my Mac. I find this way of learning any distributed systems very effective - be it Photon, Docker Swarm, Mesos, Cassandra, Big Data, Openstack, Kubernetes and such (William Lam and Tai Ratcliff have excellent blogs postings on Intel NUCs, among other things)

2) I run nested ESXi VMs for hosts whenever possible. Though they are not officially supported, they are probably the best way for training and educational purposes. You just need to have a reasonably powerful server at your disposal to run them efficiently.

3) First, pay close attention to DNS server setup. That is where I got lost and went in circles because I already have a DNS server running and I was pointing all my VMs to my DNS server, prior to installing Photon platform 1.2. The confusion arises because Photon platform 1.2 offers its own DNS service with its “Lightwave” VM that gets installed as part of the platform. And you are expected to configure Photon installer’s YAML file pointing to Lightwave DNS service (which doesn’t exist yet) and NOT to your existing DNS server.

4) I got all the required VMs in place, before I started installing Photon 1.2. This is my NUC setup.

5) I have seen many articles that teach how to build and run everything in a single virtual machine. IMHO, that is the most inefficient way of learning any distributed systems. It’s like aiming to compete for Olympics swimming but practicing in a bathtub. Only when we try building distributed systems in a distributed manner (different components in different physical or virtual servers), we will get exposed to all the intricacies involved. Running nested ESXi hosts along with multiple VMs on a single physical server, is probably the cheapest and cost effective way to get such an exposure (again, just my opinion). To that end, I have 11 VMs running on my NUC out of which, 6 of them are nested ESXi VMs.

DNS – CentOS7 VM running FreeIPA for DNS

EDGE – VM running EFW distribution, configured as network Gateway

JUMPBOX –This is your landing spot, from where you do all your activities and has visibility and access to all the VMs

INSTALLER – The appliance that you download from VMware's website that installs Photon Platform 1.2

6) I confess, I didn’t spend much time in optimizing the configurations of individual virtual machines, which might have gotten a better performance. But for now this is what I came up with, to keep myself going.

7) Here are the details of the virtual machines that will eventually run on nested ESXi VMs that make up photon platform 1.2. Later you will see the same information defined in the YAML file (pc-config.yaml) that will be used in the INSTALLER

8) As I have mentioned earlier, I have a DNS Server running, prior to installing Photon platform 1.2

9) Since NSX and vSAN for Photon platform 1.2 are not open source and are not freely downloadable, I built the platform with Openfiler to serve storage needs via iSCSI to all nested ESXi VMs (both the management hosts and Cloud hosts)

10) Let’s gets started with the configuration of YAML file

From JUMPBOX, I ssd’ed into the Photon-1.2 INSTALLER and modified the YAML file (location shown below) to reflect my current setup (You can do this directly on the console of INSTALLER as well). Once YAML file is configured properly, pass that to the “photon-setup” command (downloadable from VMware ) in building Photon platform 1.2

11) I will try to break down the YAML file for brevity. There are two aspects to this YAML file:

a) The contents should reflect your current setup (IP addresses, passwords and such)

b) It should then define where and how each component of Photon platform 1.2 should be installed and configured

12) In my setup, “Filer-Datastore” is the iSCSI Datastore that is being served by the OPENFILER to all the nested ESXi host VMs

13) Here I define the nested ESXi VMs meant to run the management components of Photon platform 1.2. Note that all entries point to 172.16.10.251 which is the IP address of the soon-to-be-created “Lightwave” VM (and not pointing to my already running DNS Server, which is 172.16.10.250)

14) The next section defines the nested ESXi VMs meant to run the workloads (Cloud hosts). Here is where Kubernetes stack gets installed (master, etcd, load balancer, and worker nodes)

15) I am installing two instances of Lightwave VMs for redundancy. Pay attention to the Primary and Secondary DNS entries. For the first instance of Lightwave VM (lightwave-1.photon.local), I use its own IP Address as primary (172.16.10.251) and for the secondary Lightwave VM, I point to my already existing DNS server (172.16.10.250)

16) For the second instance of Lightwave VM (lightwave-2.photon.local) I set the IP address of the first instance of Lightwave VM (172.16.10.251) as the Primary DNS server and it’s own IP Address (172.16.10.252) as the secondary DNS server

17) The next three sub-sections define three instances of photon-controllers. For all three instances, 172.16.10.251 (lightwave-1.photon.local) is the primary and 172.16.10.252 (lightwave-2.photon.local) is the secondary DNS server

21) Installation of NSX has to be done prior to installing Photon platform 1.2. But it is this same YAML file where NSX needs to be defined, so that it can be used/consumed by Photon Platform 1.2. Since I don’t have access to NSX or vSAN bits to play with, I am skipping them both. ( Appreciate if anybody can help me get them for evaluation 🙂 Will be glad to document and share it with a wider audience, if that is ok )

23) Once the installation completes, open up the browser in JUMPBOX with multiple tabs, each pointing to a different nested ESXi host VMs. Now you will see the photon controllers VMs, lightwave VMs and Load Balancer VM – all distributed and running on different nested ESXi VMs (management hosts - MGMT-01, MGMT-02, MGMT-03), exactly how it is defined in the YAML file

24) From JUMPBOX, point the browser to Lightwave VM. Enter the domain name photon.local with credentials as defined in the YAML file

https://172.16.10.251/lightwaveui/

Login: administrator@photon.local

Password: 1FieldDay-IO

25) And finally, from the JUMPBOX, point browser to the IP address of the Load balancer: 172.16.10.100 and enter the same credentials

https://172.16.10.100:4343/

Login: administrator@photon.local

Password: 1FieldDay-IO

26) Something subtle that is worth mentioning. While passwords for all my VMs (except the INSTALLER) is FieldDay-IO , for Lightwave VMs the password is 1FieldDay.IO .The reason being, Lightwave VM is strict about having a numeric value as part of it's password. INSTALLER VM's default password is changeme

I have now reached my first milestone where the installation of Photon platform 1.2 ends and the journey towards installing Kubernetes on Cloud hosts begin, which I will continue in my next article.

Log in as root in both VMs namely SERVER-01 (172.16.10.1) and SERVER-02 (176.16.10.2) and run the following commands. Pay attention to the IP addresses and port numbers that are being pass on each Server VM.

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!

In order to log into MariaDB to secure it, we’ll need the current
password for the root user. If you’ve just installed MariaDB, and
you haven’t set the root password yet, the password will be blank,
so you should just press enter here.

By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] <–Hit ENTER
… Success!

Normally, root should only be allowed to connect from ‘localhost’. This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] <–Hit ENTER
… Success!

By default, MariaDB comes with a database named ‘test’ that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.

Our true definition of success as a viable business is to enable individuals like you who have that fire in your belly to learn what we offer as self-paced labs, no matter where you live and what you speak.

Our end goal is to hand deliver Master-VMs through our subscription model so that you can self-learn to your heart’s content.

Partner Engineering

It’s always great to be in the partner engineering team guiding partners what to do and which way to go.

But at times, you yourself is at lost when it comes to producing your own deliverables namely SETs / Solutions Enablement Kits (or whatever your company calls them) because you’ll soon end up becoming dependent on other teams like technical marketing, product management, field enablement and so on.

By using the same Master-VM framework that the rest of the company uses, you can lock step and be on the same page with the rest of the teams. With this approach you can get your deliverables out the door on time and bring up partners on board in a consistent manner.

Product Management

You know what it means to be in the product management, how you are expected to have all the answers all the time and how everything becomes your action item.

One of the most challenging part of being a product manager is to assimilate all the information from the engineering and then spread it within the company as well as with your customers.

With our Master-VM framework, your products no longer have to live within powerpoints or wiki pages or in webex recordings. Your entire product stack with all its uses cases can come to life by packaging them into a single Master-VM along with evaluation licenses. And that can be distributed quickly in a USB thumb drive to all the relevant teams. That way, no one has to bother you on corridors or cafeteria asking for demos or product details anymore. Just point them to its Master-VM and that will take care of everything.

Technical Marketing

Technical marketing teams are expected to churn out reference architectures and white papers like pan cakes expect, nobody knows what it takes in producing your deliverables and how much you are dependent on having your own internal labs.

One of the major challenge you often face is showcasing your product capabilities and their integration with other products within your company as well as from partners and competitors. Once you figured that out, next comes the real challenge of disseminating that information to the rest of the world.

Our Master-VM framework gives you great flexibility in packing all your findings, recommendations, configurations, documentations, video/webex recordings – all in just one single VM (we call that Master-VM). It is upon us to get that delivered to your end customer, be it internal or external. This way, we completely eliminate the challenges in either opening up your internal labs for public consumption or burn your pockets by running them on a public cloud 24/7.

Technical Account Managers

As as TAM your neck is always on the line. Customers expect you to solve all their problems in a jiffy. You’ll end up becoming their sandbag taking all the blows and punches. But when it comes to training a TAM, it always seemed to be an after thought.

With all your hectic schedules and meeting up with customers face-to-face constantly, attending a full 5 day training course eventually becomes a pipe dream. You hate being dependent on someone else to help you out on the technical side of things as you never had the time to free up yourself in learning what you’re expected to know in the first place.

With our Master-VM framework, you can do your self-directed learning in your own pace. Since you are running the self-paced labs locally, you can always pause and continue your lab exercises without over lapping your work schedules. This way you can always keep up with product features and limitations first hand and deal the customers confidently.

Field Enablement

Though Architecting heterogeneous solutions have its own challenges, the primary hurdle that many Architects face is a lack of exposure to such systems.

With Master-VM framework, we build self-paced labs anywhere between the simplest to the most complicated architectures involving multiple software/hardware components from multiple vendors. Our Master-VM approach gives great flexibility, exposure and confidence in building such complex architectural solutions.

The video lessons that come bundled with any Master-VM will save your precious time in not getting yourself lost by wandering on the net looking for clues/answers but stay laser focused on mastering the concepts quickly without any diversion.

Consulting Architects

The management wants professional services organization to be a cash cow for the company. But somehow doesn’t want to spend on the required technical training (?!) Ask them for a training and all you hear are budgets cuts, quarterly endings and cost cutting.

We understand your world. And that is why we kept all your training requirements as the fundamental corner stone while designing our Master-VM framework. You no longer need to convince your reporting chain all the way up to a VP to get the required training. All you need is your laptop, your physical server, your time commitment and the rest is on us.

In fact, for some of the self-paced labs that we have designed, we have even eliminated dependency on an internet connection! That way, you can be in hotel room in a different country altogether, but you can still spend a few hours wisely in learning the product capabilities of your choice using our Master-VM framework.

Sales Engineers

Our Master-VM framework provides you an alternate and cost-effective way of carrying your demos and proof-of-concepts with you on your customer visits which instantly become your sales tools.

Your sales cycles can be much shortened by leaving your portable servers at your customer site for them to play with your stack if needed, rather than try building sandboxes for them on Cloud and then baby sitting them.

You no longer need to burn midnight oil in preparing for your next day demo. But instead a single Master-VM can build your demos and poc’s with all the use cases that you see fit. This way you can showcase product capabilities effectively and quicker.