Just like a teacher told me, the Linux is not a presentation operating system. Sorry, I expected that I had a computer here.

Hello, my name is Everton Foscarini. I am presenting here virtual monster plus nginx. I have an update of the title, hosting more than 250 open sites.

And now from five different blowing backends, more than 500 Apache and 200 ASP sites in a single host name. Who am I? I am Cesar Jimin in our university, URGS. I work mainly on Linux and email, the email server, the

And the most work is in virtualization. What is URGS? URGS is the biggest federal university in the south of Brazil, established in 1934, and has internet presence

since 1990. This is the oldest archive in the archive.org from 1997. And then we have a major re-stilization in 2004.

That lasted until 2011. And this, the new 2011 to plenty site that is available to now. Why all these sites? Because the university has a lot of history in the internet. We have hundreds of sub-sites, the department sites.

The main site is a sub-site of the main domain. We have the IT department, the e-learning, the computer science, the medicine, all the main departments and laboratories and libraries, all have sub-sites.

And many URLs have more than 20 years. So legacy matters here. We had some challenges in the hosting service in 2010 because we have silos. Disconnected hosts, the main site, www, was Windows and

IIS, the second, Linux with Apache, and the new, in 2009, we started using Plon3. And have a lot of others, different host names, www2,

www3, www4. I think that 11 is the last one that we have. And mixed types of contents, mixed types of servers, and a lot of different administrators. And all the websites want to have a www URL because it's

built here, cooler to have a www, others not, a www23 as you will get to put in documents, in material.

And the IIS had hundreds of rejects just redirecting to the www6, www2, the paginess. And when a site was migrated to another, to Plon3, we have one more redirect to configure.

Other problem that we had was that Plon3 had multiple host names. The first configuration, the Nginx, has had a mapping of the host names, from the host names to the sub-site.

So the same site had three addresses, CPD, the IT department, www CPD, and pages, paginess, slash CPD. And we have also the redirect from www URL slash CPD to the paginess slash CPD.

So we had at least 40 sites with this configuration, the same content, three different URLs to Google to index, and Varnish had to cache for three times the same object. Other challenge, we had to start using Plon4.

We have some problems of performance with Plon3. And the problem to upgrade was that we have some spurious products that didn't behave correctly and could not upgrade the site to Plon4. So what we should do, create a new host, paginess 4.

We also had to upgrade the Linux server. It was a Debian 4, very old, full of broken sites and holes, Debian 4, it wasn't supported anymore.

But we could not just upgrade because we couldn't break sites. We had PHP 4 and PHP 5, and the users didn't upgrade their code to use PHP 4. And we had more than 300 sites to test in a upgrade.

So should we create another new host? And in the end of 2011, we have to change the site or migrate to Plon4. But we still had more than 300 sites using the Windows

server that has the www address. So we could have three possible solutions. Or we create a new site, new URL for Plon4 and create just one redirect. We can steal the address from the Windows server and

rename the Windows server and have 300 redirects to configure. Or we could create a reverse proxy, the only same solution, and clean up all this mess. So that was what we have made.

I will share the presentation later. This is the current status. We'll talk about this later. I made a first try in 2010 just because I wanted to have a reverse proxy in front of the Windows server just to take it out of the front of the page so I can have some

redirects, some different content. But I made a single host. I had a single point of failure. Apache had problems. It was just Apache without modulus, without specapp, had some problems with the medium load.

It wasn't in the SATs, the visible R. The time that we had more than 40,000 visitors. It was a normal day. And the users used the FTP connecting to www.

So I have to have FTP portrait reactions just to don't upset users. So I keep for one week and must have to roll back.

A second try was made in 2011 because we have to migrate the site. So this time I made it right using GenX and load balancing. Load balancing since the beginning to have mainly fault tolerance, had a good performance, and the FTP users

must use the correct DNS server. They spent six months after changing the DNS. The users are still calling to know where was the server. So they were obliged to use the correct server.

So the main goals of the reverse proxy for the hosting part, not for the main website, was that any hosted site must have the www slash site address.

So the sites must be either in IIS, Apache 0.3, 0.4, WordPress, any backend should be supported. And the website can migrate between hosting servers

because they don't have to make a redirect. The content migration, I don't care. The users want to have the address. So the address are theirs. So we can migrate from one backend to another without problems.

This was the first production setup with the reverse proxy and the IIS, Apache, and 0.4. I had three servers, not just one reverse proxy, one just to make an example here.

And we had 0.4 supersized infrastructure because of the problems of 0.3 installation. We were very cautious, created two varnish servers, separated the 0.4 servers had just varnish to have

fault tolerance, and two servers with clients, each one with two clients. And the server, it was in a better machine with storage.

Trying to, the ZODB wasn't fault tolerant, but it was a drawback because the ZODB replication, it wasn't free software in 2011.

So the configuration in GenX, it was made into parts. I created a location for the backends here in the down. Each backend has its location at the beginning. And to define to each site in which location it should

find, meet the request, I have the at, plony, at the end of the try files. So I have a maintenance page. If I want to remove the plony from the website, I can just

create this HTML. And the GenX will provide this page just saying that the plony is in maintenance. I had the setup to have a simple configuration for the backends. But the talk was about virtual host monster.

VHM is used to generate HTML according to the rules in the URL. What means this? I can have, this is made in varnish. I can say if the site is public, use the www.orgs.

If the site is to management, use the plon.orgs. And the content is the same, but it is generated according to the URL. This is a request directly to the client where I can show

the virtual host base. And the fake test URL. So the generated HTML has the fake test URL as the host name, part one. Totally fake, but this shows that plony generates the

content according to the configuration in the VHM, not in the requested host name from the web browser. So going back to the hosting. Now, the varnish was in the middle of the field, but I

now move it inside the Plony machines. So we can have a granular configuration. The Plony works, the main website has a more aggressive

policy for cache, and the others have different. So the main website has the content managed by the public relations, mainly news and events. Uses memcache and the web service. The web service takes from the internet, from the

institutional database, some configurations, some list of teachers, professors, list of courses, and this data is stored in memcache to alleviate the server.

And we have a talk about it today, about the site. Plony pos is a kind of internet for several graduate schools, uses the same configuration. We have the Plony hosting, hospitalizing. Generic hosting is where we have the more than 250 sites.

We have a restricted product collection, selection just to don't have problems with products. We have a talk about this tomorrow. And we had some migration from Plon3, PlonPaginas, and

Plaginas2, because they were migrated in different types, and have different versions. And we have the new Apache server, whose migration was made slowly, side by side. And the old IIS, and now a WordPress.

How do we configure Nginx to deal with multiple back ends? I have multiple locations. I have more than 10 locations connecting to back ends, just like before. So how do I say to a website, this is an example, lab solos, which location use?

It should use the location colossus, is the Linux Apache. The other site, Progesp, is the human resources, uses the migration, PlonPaginas, the migration. And here I make the first part of the VHM configuration, where

I say here, after VH is the final URL. I'll talk about this later. But this kind of configuration for each one of the 800 sites is a bit complex.

So we created a kind of reverse proxy config file, where I can say for each URL, in which back end it is hosted. And we have a script that generates the Nginx configurations, and should just reload the Nginx

configurations done. A new site, so it's just two lines, one line. The final touch in the hosting, Ploni, we had multiple datafests. So we can segment the department, the sites by

type, departments, laboratories, libraries. Look at this as a good idea in the beginning. So we can have separate partitions, can enforce quota, have smaller backups, less DB packs, because some sites are less dynamic. And maybe it was better before blob storage, because

blob storage separated all the big files from datafests. And we had a final drawback. The ZODB mount path must be in the URL. So we had to redirect again. But VHM comes to save the day.

And just like I said, the VH configuration says that this is the URL, CPD, doesn't matter in which mount point, or even if this name of the site was other, doesn't matter, the VHM can create the correct HTML.

So we have here the hospitalizing, located in the mount point to Unidad with the VH CPD, degenerated HTML has just the CPD sub-site.

Conclusions. We have success enforcing a single public host name. And we created a GenX redirect server just to handle old virtual hosts, so this site has 40s, 50 virtual hosts just

redirecting. And we made a policy. Every site should have the www.wirs.br address. And these are the numbers of the sites still now, always growing. The reverse proxy configuration file make it

manageable, create all that redirects for each site to be painful. And VHM gives deploying a great flexibility. We can rename a site. We have already made it, a department changed his name.

We just had to create a new line and say, now you should use the other name. This VHM can hide mount points. I don't remember. And with VHM, we can create a different URL, in this case,

plowing.wirs.br, that could have been accessible just inside from the university to don't enable the authenticated pages to be available outside. So now we can migrate backends, maintain the same

URL, and I think that I don't have time for questions. You have my contact here if you want to make a question. I will publish a link for the slides here later. And thank you.