Adding CSVs on Windows 2012 R2 Hyper-V Failover Cluster

In the first part of this article I have added some physical and virtual disk to my Dell iSCSI storage. Of course new vdisks do not appear immediately in the failover cluster manager console.

 

So I opened up my disk management console on my hyper-v host.

 

As you can see a new raw disk appears. We should bring it online, initialize, format and provide the disk a descriptive name.

.. and try to add it again by the FCM console - this time surely with success. But this is going to be only an "available storage" - still needs to be added to the failover role.

 

It's a good practice to rename the new disk to ease further identification and error hunting.

Voila, the new clustered virtual disk is ready to host my new VM's image files, you know the .vhdxs and so on.

Keepalived and squid as a load balancer

Okay, we have 4 servers to loadbalance and failover the web traffic. The first two servers hold a shared IP address with keepalived:

/etc/keepalived.conf
global_defs {
    notification_email {
        roto@masterkey.com
            }
    notification_email_from roto@masterkey.com
        smtp_server 172.16.2.200
        smtp_connect_timeout 2
        lvs_id LVS_01
        }

vrrp_instance VI_1      {
                        interface eth1
                        state MASTER
                        virtual_router_id 51
                        priority 99
                        smtp_alert
                authentication {
                    auth_type PASS
                    auth_pass SECRET
                            }
                        virtual_ipaddress {
                        172.16.166.23
                        }
#                       track_script {
#                       chk_haproxy
#                       }
                        notify_master /etc/keepalived/master
                        notify_backup /etc/keepalived/backup

}

On the slave node, everything is similar but the priority. You can touch anything into the master and backup scripts, e.g. /etc/init.d/squid3 restart (Just to make sure that squid picks up and listens to the shared IP. No. I don't think it makes sense.)

Squid3 runs on both frontend nodes as

[...]
cache_peer 172.16.166.21 parent 3128 3130 proxy-only round-robin login=PASSTHRU
cache_peer 172.16.166.22 parent 3128 3130 proxy-only round-robin login=PASSTHRU
dead_peer_timeout 15 seconds
hierarchy_stoplist cgi-bin ? ebolaplay
cache_mem 8 MB
maximum_object_size_in_memory 1 MB
memory_replacement_policy lru
cache deny all
cache_dir null /tmp
logformat squid %ts.%03tu %6tr %>a %Ss/%03Hs %<st %rm %ru %un %Sh/%<A %mt
logformat squidmime %ts.%03tu %6tr %>a %Ss/%03Hs %<st %rm %ru %un %Sh/%<A %mt [%>h] [%<h]
logformat common %>a %ui %un [%tl] "%rm %ru HTTP/%rv" %Hs %<st %Ss:%Sh
logformat combined %>a %ui %un [%tl] "%rm %ru HTTP/%rv" %Hs %<st "%{Referer}>h" "%{User-Agent}>h" %Ss:%Sh
access_log /var/log/squid3/access.log combined
cache_store_log /var/log/squid3/store.log
cache_log  /var/log/squid3/cache.log
logfile_rotate 8
[....]
Of course 172.16.166.21 and 22 and the backend Squid servers. On these servers, there are nothing special. Caching is set to ON but no use of logging the source IP addresses of the request because they are already containing the frontend server IP address here.