CinciTech

Members
  • Posts

    4
  • Joined

  • Last visited

Everything posted by CinciTech

  1. To re-clarify, we are running the Windows version, on Server 2016. We are not currently running the Linux QDSM (but would like to in order to eliminate a Windows VM). I might try to put a drawing together in Visio to help illustrate, but... ESXi 6.7 is the operating system on the SuperMicro. It is designed to do little other than run virtual machines, including Windows Server 2016 & Photon 3.0 in our case. We are already running a handful of Photon 3.0 VMs with Docker containers and they work amazingly. In one case we replaced a Windows certificate authority server with a Photon using OpenSSL for CA; this reduced the RAM and CPU utilization from 8GB to 20MB and a couple GHz to 0Hz most of the time (and saved ourselves a Windows OS license to boot). So, I'm 100% confident I can throw another Photon VM and stick Docker containers in it. All I would need in my case is a containerized version of QDSM, (which it seems may not work until we cough up more money for Enterprise licensing, so I could be dead in the water already). ESXi stores virtual disks in "datastores", which can be a local disk or a NAS/SAN, so the fact that the virtual disks will be on a NAS is mostly for reference; it's not a potential limitation for a virtual environment. We have a bunch of customers' QBD files on a network share, so our "database" is a whole bunch of random QB? files. The share includes a fair amount of backed up company files as well as all the temp files Quickbooks creates, so it's hard to know what our true "database size" is. It seems we have about 11.5GB of QBW files, which may be the closest thing I've got to an accurate count. It is a Windows Server 2016 file server with all the roles and features installed for CIFS and DFS replication (although we don't currently have a secondary file server stood up for replicating anything to). The file server VM is allocated 4 CPU cores and 8GB RAM; it is using right around 2.1GHz and ~400MB RAM, according to the virtual monitoring in ESXi. With all that said, I have to believe most of that is consumed by the Windows overhead, and although I can speculate and say I believe a Linux VM running QDSM and Samba would need a fraction of those resources, I cannot say for certain how much it would truly need. With that great big disclaimer in mind, I would think you've got plenty of CPU/RAM to at least try deploying it on your NAS in a container, providing you're able to deploy containers in your NAS (I haven't messed with ContainerStation so I don't know how easy it is/isn't). If it's too much for your system you can always shut down the container and go back to what you're doing today. I think the difficult part here is that no one has created a containerized QDSM yet.
  2. We're not using the Enterprise version. We use the Quickbooks Pro and Accountant versions. I'm good with offline discussions, although I suppose it may be worthwhile to share in another thread what we've got and how it's configured; maybe it helps other people and maybe someone has some improvements for me. This is the first I've heard that the Linux QDSM is Enterprise-only, which would be disappointing if true. We're signed up with Microsoft Volume Licensing, which is surprisingly affordable, especially compared to VMWare's High Availability package (unrelated rant to be held over drinks at some bar somewhere else). The VMs are stored on the QNAP, but they run on SuperMicro rack-mount servers (roughly 2.5k each, but they also provide for email and web hosting and internal chat, so it was easier to absorb). There is a Windows 2016 file server with QDSM running on it where all the various QB files get stored. Installing QB on an RDS is fairly straight forward, with QB Pro & Accountant versions installed using the "Install Application on Terminal Server" shortcut in Control Panel. Ideally, I want to create a Photon VM, add a virtual hard disk just to store QB files, then create/deploy a QDSM container with the virtual disk linked as the data folder. Maybe a SAMBA container would be needed to share the QB files over CIFS to Active Directory users (I'll need to learn more about the Linux QDSM to understand that). In my case the Photon VM would be stored on the NAS and run from the SuperMicro server, but if you have a NAS capable of running Docker containers then it could all run from there (assuming the CPU and RAM were beefy enough). And Windows Docker users would equally be able to run the same thing, which is the magic of containers in the first place.
  3. I'll throw in my thoughts, which are directly related to my experience and may or may not apply to everyone's use-case. I manage a virtual platform with two physical hosts running VMWare ESXi 6.7, virtual machines run from a QNAP NAS and are backed up to a Synology NAS, and I've fallen in love with VMWare's Photon OS as a super-slim VM that comes with Docker pre-loaded, all in a 155MB download. It's designed to use minimal resources, as we all generally understand that Windows is a resource hog. I've had great success deploying Docker containers for everything from PiHole and Nextcloud to MySQL/Wordpress/Adminer/FTP/CertBot (Let's Encrypt) for public hosting of multiple websites. I haven't yet taken on the challenge of creating a Docker container from an existing project, although I plan on trying this when I get some time. Firstly, this thread is about running the Linux QDSM, potentially in a Docker container, so most of your numbered points either wouldn't apply or are answered by virtue of how the Linux QDSM the OP linked would (theoretically) work in a Docker container. We also have QDSM running in Windows Server 2016 with various versions of QB running from a Windows Server 2016 RDS and it's been pretty solid. Having said that, I believe everyone should accept only as much risk as they can be comfortable with in their environment. I virtualize everything I can because backups are simple, snapshots can protect you from problematic updates where you aren't able to test the updates in a sandbox environment, and resources can be allocated pretty much on the fly when you find you need more. Should we roll the dice? I think as long as you have good backups of your critical data along with regular restore tests to prove you can go back when needed, you're no less 'safe' than however you host your data today. The benefits I'm looking for in this approach are reduced resource utilization, increased performance, and reduced footprint in my backup pool (IE: quicker restores from backups in the event of anything from hardware failure to ransomware attacks). I wouldn't deploy such a thing if it weren't properly vetted in my environment, but if it were to test well I would be comfortable rolling the dice as long as I can simply "undo" if it comes up snake-eyes. So, I posted at the end of July and haven't seen any updates since January. I will hopefully go down this path and post my results for anyone else interested, but I'm curious if @ForgottenPoundSymbol or anyone else has had any luck Dockerizing the Linux QDSM?
  4. Just learned today that there was a Linux-compatible QB database component, and immediately Googled (without hoping to find something) that someone went and tried it out with Docker, and then I found this thread. Sorry in advance for digging up a 7-8 month old post, but I just wanted to touch base here to see if anyone has gone any farther with containerizing the QB database server? I support an customer who uses QB 2014-2019, and while it's been "okay" to use a full Windows fileserver VM to store the apparently-required-because-Intuit-can't-manage-files-using-CIFS/SAMBA-like-everyone-else-does Database Manager component... But being able to isolate it onto its own lightweight virtual appliance would be much easier to manage. I've had a lot of success moving various network services to Docker containers on VMWare Photon 3.0, so I'm likely going to head down this path and I'll write up my findings for others. In the meantime I'm just looking to see how far others have been able to carry this football.