Open federicopuntoni opened 6 years ago
Can you clarify a little? Certainly storing some content on EFS and some on EBS is certainly supported and might be achieved with careful configuration of mount points. The advantage of EFS is simplicity; you don't have to worry about synchronising content on EBS volumes as new instances launch. If you store any content on EBS you would have to ensure the content is synchronised with each launch and deployment.
By "versioning for plugins" I expect you are considering a backup/roll-back capability? This is something that you might implement with the EFS-to-EFS backup solution, in conjunction, and synchronised with, database backup & restore.
https://aws.amazon.com/answers/infrastructure-management/efs-backup/
This is probably something best managed through a WordPress specific Plugin to Management tool.
Ok, what I meant to say is, as we read on the web, EFS may have problems handling a high i / o. There are users who complain about high latency when the traffic on the website is high and the size of wp is very low, managing EFS the i / o based on the size of the file system.
I can not understand if this is to be considered true.
"This is probably something best managed through a WordPress specific Plugin to Management tool."
You have some plugins to advise me in order to manage the correct devops between a development and production environment. For example, how can we solve the problem that may arise if the production db is constantly modified by the publication, on the website pages, of comments from users even during local development?
Is it possible to use S3 with CloudFront for all the wp-content instead of EFS? Pros and Cons?
Hi @RGuilfoyle. A note on this - I created an environment, and the immediate blocker for me was EFS performance. I think you should consider adding cachefilesd or a similar solution. A simple get_plugins call in a real world solution can take up to 20s on EFS with ~ 1.5GB of storage in use, compared to EBS ~ 2-3s.
Compared to other HA solutions, this seems to be much less performant and not cost effective. I used a variation of the helm chart from Bitnami for comparison(see: https://github.com/kubernetes/charts/tree/master/stable/wordpress) I tried both GlusterFS and an NFS pod on gcloud and it was much more performant.
Regarding caching, cloudfront has limitations when compared to [Route53] --> [regional/federated cluster] --> [Varnish] --> [wordpress pod] --> [ object caching pod ]
Is this still considered a reference architecture as far as Amazon is concerned? I feel that EKS should be the go to solution (while still using RDS)
You need to fill EFS with dummy data to increase the size to be offered more performance, the size of efs determines the performance offered. Like a Raid set. There is a Dummy data field in the template, increase it to match the performance wanted in the table in the link https://docs.aws.amazon.com/efs/latest/ug/performance.html
Due to EFS credit balance can be a correct way split wp-content to EFS and EBS and apply versionising for plugins?