5 Replies Latest reply on Dec 23, 2016 9:13 AM by krheinlander

    Optimum number of partitions in a single drive FileMaker Server deployment?

    TonyWhite

      FileMaker, Inc. has traditionally recommended 3 partitions for setting up a FileMaker server machine (this was before the Progressive Backup feature was introduced...more below):
      p1. OS+FMS install
      p2. Databases
      p3. Backups

      Having the OS and FMS on a separate partition gives you the ability to clone the partition or to redo the OS+FMS more easily.
      If you are running on a machine with multiple disks you have the possibility of having different parts of the deployment running on different disks and therefore bringing more I/O (and therefore more speed) to the deployment.

      When FileMaker 12 shipped, Progressive Backups were introduced...which made me think that perhaps 4 partitions might the correct number.

      As developers, we often find ourselves deploying FileMaker Server to machines that have less than ideal hardware, and where the only decision that is up for discussion is how to make the most of what we have. More hardware is not an option in this case.

      We are working on a project where the client will be using a Mac mini with a 1 TB drive, 2 external drives (for more local backups and emergency boot clones) plus CrashPlan for off-site.

      The database files are relatively small and are not expected to grow.

      The hard drive was set up with 2 partitions with the thinking of 1 partition for the OS+FMS and one for the rest...since parts 2, 3, and 4 were all on the same physical disk there was no (disk failure related) advantage to partitioning. Perhaps this is true? You might even make the case that 2 partitions is better then 4, as it is more flexible in terms of the size of the elements ( Databases, Backups, Progressive Backups) that are on the 2nd partition.

      Within the parameters of the setup described above, what do we think is better 2 partitions, 3 partitions or 4?

      Thoughts?

      Thanks.

      Tony White

        • 1. Re: Optimum number of partitions in a single drive FileMaker Server deployment?
          mikebeargie

          I don't usually deal with partitions anymore, just separate drives. This is much easier with virtual drives (EBS) to setup, partitions may still be the norm for physical installs.

           

          Our standard "virtual" partitions are either:

          1) System OS

          2) Database / Backup Drive

           

          or:

          1) System OS

          2) Database Drive

          3) Backup Drive

           

          In the cloud we really haven't seen performance differences between either of those two setups, but the ability to "reattach" a drive to another server instance has been miraculous.

           

          If I was doing physical install, I would most likely still have dual drives or arrays, and partition one disk into the OS partition and the Database partition, then have the second drive be the primary backup destination.

           

          Partitioning I believe also results in different performance from spinning drive media vs. SSDs, so that's something else to think about.

          • 2. Re: Optimum number of partitions in a single drive FileMaker Server deployment?
            RickWhitelaw

            Why partition ar all? I'm on Mac OS and never partition a single drive. On some machines I have several drives though.

            • 3. Re: Optimum number of partitions in a single drive FileMaker Server deployment?
              TonyWhite

              In the FileMaker® Server15 Getting Started Guide
              fms15_getting_started.pdf
              ...on page 73:
              Setting up and configuring Windows

              Recommendation
              Configure the disk subsystem

              Do this
              Configure the disk array into three logical partitions.
              1. On the first partition, install the operating system and FileMaker Server.
              2. On the second partition, store the databases that FileMaker Server will host.
              3. On the last partition, store local backup files and performance logs.

              As to why FileMaker, Inc. is making this recommendation...that is a question for TSGal, TSPigeon, or someone else from FileMaker, Inc. to best answer. (not sure why the Recommendation would not also be listed under OS X)

              I see some reasons for partitions as stated in my OP. That said, questions about best practices remain.

              Hope that helps.

              Tony White

              2 of 2 people found this helpful
              • 4. Re: Optimum number of partitions in a single drive FileMaker Server deployment?
                RickWhitelaw

                Ah, i see what you mean. But I have no idea why FMI suggest à this.

                • 5. Re: Optimum number of partitions in a single drive FileMaker Server deployment?
                  krheinlander

                  I think I can understand this, relative to rotating media. Once the OS and FMS is loaded, few, if any seeks to track/sector locations in that partition would be required. All disk I/O would occur within the data partition, keeping the track latency down. In addition, moving the backups to another partition would also keep data fragmentation down, so that the FM data area would be closer to sequential seeks, all of which would improve performance over time.

                   

                  All this becomes a mute point, to some degree with SSD drives, but even less so once disk controllers move from the AHCI (advanced host controller interface) command set (designed to deal with track/sector seek latency and queueing)  into the new NVMe (non-volatile memory host controller) SSD type controllers, that treat SSD storage like random access.

                   

                  IMHO, at that point, there is no real advantage to partitioning disk, and it could even be a detriment based on memory cell "wear" that degrades SSD integrity over time (which is why all modern SSDs have storage algorithms to account for movement of repeated written/read data location to new locations to minimize this impact).

                  2 of 2 people found this helpful