Before I get started:
- By remote, I mean from another machine – I sincerely hope that you will not be opening your Final Cut Server database to the WAN. So again, please be careful with this as there is no security around the database and you will be limiting access via IP for now.
- This article lays the beginning framework for a series (no promises on when the next in the series will be posted) on clustering the stored role of Final Cut Server, which provides the database (back end functionality) of Final Cut Server.
- All of this is done using built in tools for Final Cut Server.
- Don’t do this unless you absolutely have to (ie – you’ll be clustering your databases using the instructions in this series).
- To my knowledge, absolutely none of this is supported by Apple, (AppleCare, etc).
- Don’t roll ANY of this into production without fully testing/vetting yourself.
In order to be able to connect to the database remotely, you first need to enable a listener for PostgreSQL. In order to do so, open the /var/db/finalcutserver/data/postgresql.conf file using your favorite text editor. Then uncomment out the following line:
listen_addresses = ‘*’
Now, change the * to the IP address you’d like the daemon to listen on, unless you want it to run on all available IP addresses (or you just have a single IP). Close the text editor, saving the file in the process. Now, let’s define which IP addresses can connect to the PostgreSQL database by opening /var/db/finalcutserver/data/pg_hba.conf in your favorite text editor and adding the following line (you can replace the cidr address here with the one that you prefer to use) in the IPv4 local connections section:
host all all 192.168.55.0/24 trust
Now, this is the only real security you are going to have. There is no signing or encryption involved with these packets, so do so on a trusted (out of band) interface, don’t do it on your production network. Also, limit the cidr address to allow for the absolute smallest set (if you’re going to replicate the database between four hosts then consider using a /29 or if there are only two consider using a /30).
The preferable way to do something like this would actually be to use an SSH tunnel or simply SSH into the remote host. It just turns out that when we do that the replication doesn’t work properly (so far). I will continue to look for a better, more secure way, but for now, if you use an out of band network for security then the lack of encryption is fairly mitigated. Again, I know that this is not how you would typically want to do it, but for reasons illustrated in future articles it is going to be the first step in the clustering process. Also, you will want an out of band network anyway, given that you don’t want database sync streams to interfere with Xsan metadata traffic (if your Final Cut Server data is stored on a SAN) nor with the bandwidth that end users have into your Final Cut Server environment via your non-Xsan, client facing Ethernet connection.
Once you have made all of the changes, you can reboot. Once done, you can connect and test the connection using standard PostgreSQL tools. Or just port scan the port defined (by the amazingly complicated port variable) in the postgresql.conf file.
Now it’s time to think about what exactly you’re looking to get out of your clustered PostgreSQL database. For example, in some cases you may be looking for load balancing the back end PostgreSQL functionality (aka stored). Whereas in other environments you might actually be looking at simply providing high availability via point in time recovery methods (the server crashes and another pops online a couple of seconds later to keep users chugging along) – this is the concept of active-active vs active-passive, respectively. This series assumes you’ll be using automated failover, although provided I get around to it, I’ll try and cover both by forking the series. This series also assumes that all hosts are using identical mount points to access data and that you are using two different serial numbers with your Final Cut Servers. Both Final Cut Server instances need to be using the same paths to access both data and the database. This may be via nfs, symlinks, cvfs or whathaveyou. In cases where an operation will not function over a specific protocol/file system I will indicate that; however, when it comes to bottlenecks, I will rely on feedback and further experience to identify those.