There are ways to use S3 as the store for source images by using tools like s3fs (FUSE-based file system backed by Amazon S3) and writing front end code the intercepts the incoming WMS request, filters using a grid, then routes to the appropriate EC2 MapServer instance. This allows particular instances to do region based caching of source data. First request that "hits" a new source file is slow, but second one is read from EC2's "built-in" storage. This kind of setup allows you to run n-number of mapservers all looking at the same data stored on a S3, but would require some work up front. The smaller the grid, the more mapservers. and if you want to scale more you can use LB and autoscaling.
On Fri, Jan 28, 2011 at 2:41 AM, <[email protected]> wrote: > Hello guys, we're a startup and new to mapserver. We're expecting large > amounts of data to come by (at least on our scale) around 40-60TB of raster > images for mapserver to render. My question is for the infrastructure, what > is the best way to store this (cost-efficiently)? > > - Do we just get a dedicated server with a lot of HDDs? I'm looking at a > 48TB setup in RAID 1+0 so i get 24TB right what happens now if we need more? > Also, how can we scale from the mapserver side? Is access to different > storage servers possible? > - I've considered SANs but then it's not practical right because only one > machine will access the storage? > - What about Amazon's S3? or EBS? Anything we can use on that? > > I wish to get awesome advice on this storage issue, basically what the > considered best practice is for the mapserver people :P Thanks > _______________________________________________ > mapserver-users mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/mapserver-users > _______________________________________________ mapserver-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapserver-users
