I’m trying to implement a solution of KumoMTA in AWS ECS.
I’m running KumoMTA on ECS Fargate, and I woried about the persistence of the Kumo regarding making sure that emails that are send via Kumo are delivered and not lost.
What I’m worried about is for example if the KumoMTA ECS task goes down because of crash/scale down or any reason AWS stopped the task, I may loose the ongoing emails that exists in the Schedule Queue.
So I wonder if we have in KumoMTA some support for persistence in that case with ECS.
I though about adding SQS queue before the Kumo, and let the SQS retry and send the message again to KumoMTA so that we make sure the email arrives to the recipient.
Fargate is a new one for me. Most of our customers wanting container orchestration are doing so with K8s. The spool and log locations are definable and are designed to be mounted in attached volumes so theoretically, if you can define an external storage location and connect to it reliably, that might work. BUT that comes with some huge caveats.
If you are standing up external storage, it will need to live on a server and you might as well just run KumoMTA on it at that point.
At the speeds that KumoMTA functions, external storage can severely impair performance. NAS or SAN solutions are typically less effective than local storage.
In my experience, Bandwith cost dwarfs instance cost, so moving to Fargate for cost savings may be ineffective anyway.
Can I have more details on persistency about what you suggested? As I understand currently, what you suggest is NAS or SAN storage solution for the persistency using k8s?
How can I accomplish persistency using that? let’s consider we have several Kumo services running in parallel
Sorry if i was not clear. My recommendation is to use a stateful system where the storage can be local and persistent. IE: not Fargate. If you choose to move forward with Fargate, you might want to try NAS but we do not recommend it.
Hi,
I’m still not sure how local storage can work with multiple instances of KumoMTA with persistency.
Let’s say I have several pods in k8s that are running KumoMTA instances, each pod will have its own local storage that will be lost onces the pod dies. so how can we accomplish persistence with local storage in k8s?
IMHO this is a KumoMTA question, AWS/k8s options are clear. The question is what are the best practices for ensuring persistence when running multiple dynamic KumoMTA instances (doesnt really matter on what cloud provider)? any references for such information?
Persistence in a VM is a VM question. KumoMTA will run on anything with a disk, and to not lose the spool that disk should not be ephermal. If you’re asking if KumoMTA has a mechanism to create persistence independent of the system it is running on, it does not.
Users can flush an instance back to the firewall to bring nodes up and down, but in my mind that is still not fault tolerant, which is how I interpret the question. If those nodes have ephermal disks and shut down while still processing a spool, those messages are lost.
This isn’t really a KumoMTA question, but with my previous employer, we use web apps that use ECS among others (like Lambda and even ElasticBeanstalk) but those apps forward emails to an “ordinary” KumoMTA server. We were able to send 500K emails/day on a single server and even then it was still underutilized. I’m pretty sure that we still had capacity to send another million or two emails. Haven’t really encountered a scenario where you need a complicated setup that needs KumoMTA on dynamic instances or something.