In a sort of response to deed02392's answer, there are ways around these problems mentioned, but it largely depends on how your array is setup. I agree totally that RAID-6 on its own is in absolutely no way secure, people want to be able to add and remove drives from a RAID array and want to recover in case a drive dies, so if that's possible, you can rest assured that an adversary with physical access to the disks could get what he wants once he figures out what order the drives are in.
If I were to setup a RAID-5, RAID-6, (or 1, 10, 50, or 60 for that matter) and I valued data confidentiality, here's what I'd do.
Issue Secure Erases
Immediately upon receiving the devices, issue SATA secure erase commands on all of the drives. Don't write anything to the drives at all. If you're needlessly paranoid,
dd if=/dev/zero of=/path/to/device. Remember to do this on all of your devices.
Setup the RAID Array
Your process will diverge into a number of possibilities here.
If you're using hardware RAID, you'll need to unplug all of the drives after issuing the SATA secure erase command to them (and writing zeroes, which is pretty unnecessary and only makes you feel more secure) and plug them into your RAID controller. Go into your RAID BIOS or configure the RAID setup from your operating system of choice, though usually the RAID BIOS is easier to work with than running a series of commands which seem to be designed to be confusing. Setup your RAID level, then reboot into a secure Linux, maybe Kali if you're paranoid.
This is more complicated and you get a number of choices here. LVM? ZFS? BTRFS? There are a number of ways to setup software RAID, so I can't be of help too much here, Google it for yourself. Just make sure that at the end of all the setup, you have a single device (virtual, probably) that you can write to which correctly spans the length of the array.
Randomize the Entire Span of the Array
This step is optional, but highly recommended. It protects against certain deniability concerns, which I'll explain below. It won't protect you if you're forced to decrypt the array for someone. The simplest way to do this is to use
/dev/urandom or another secure cipher with
dd to overwrite everything:
dd if=/dev/urandom of=/dev/mapper/raid6blockdevice bs=SECTOR_SIZE
parted /dev/mapper/raid6blockdevice print to determine
SECTOR_SIZE. This could take a pretty long time to complete.
The outcome of this step is that every bit in the array as it exists on the SSD is effectively random. Someone can't tell "how full" your filesystem is, as the entire thing is random bits, as the output from a good cipher should be indistinguishable from random data.
Setup LUKS/TrueCrypt/VeraCrypt/Your Disk Encryption of Choice
Using your disk encryption weapon of choice, encrypt your block device, then install a filesystem inside.
In response to your concerns about the SSD secretly internally storing the LUKS volume header, you're right that it's possible. Buy a $5 USB flash device and store the LUKS header on there instead of on the SSD array. I believe there's a way to do that.
Without that, be aware that if you ever had to burn down the house (destroy everything!), you'd have to have physical access to get all of the SSDs out of the server, connect them to SATA, and secure erase. Even with that said, it's hard to be completely sure that everything has really been erased. Start working in the data recovery field and find a SSD which secure erases reliably, or at least ask a friend in that field. Without assurances and in a bind, I'd probably just write a loop which forever rewrites the LUKS header with random data hoping that the SSD with all that writing would eventually replace any sequestered data with new data from randomness.