Leslaw, I'll try to answer your questions inline.
Regards 2012/5/2 Leslaw Zieleznik <[email protected]> > > I am trying to work out the disk storage on the multiple server > installation, and I am unclear in few places of the 'Install Across > Multiple Servers V.1.3' document. > > 1. I understand, the Workspace should be installed on a shared volume and > the > org.opencastproject.workspace.rootdir should be pointing to this > volume. > The question is, what is the recommended size of this volume in > proportion to the projected size of media storage? > I understand that Workspace is a temporary storage? > The workspace is (as its name points out), the "space" where all the "work" takes place; in practice, the location where the files to process are copied and where the resulting files are created before being copied to their final locations. It is "temporary" because the files there are supposed to be disposable once they have been copied in their final destinations, but that's not done automatically by each service --you have to specifically delete the unneeded files using the "cleanup" operation in the workflow. It should be in a shared volume if possible, because otherwise the files are copied via HTTP, which is slower than using a distributed file system such as NFS. I cannot tell you how big that storage should be in comparison with the media storage, because we have been using the same volume for the workspace *and* the storage, i.e. we don't mount the workspace and the share storage separately. However, I guess it depends on how many simultaneous jobs are done at the same time in the installation, and the size of the files involved. As the files are not erased till the end of the workflow, you need to account for the whole size of all the source files, the space for all the resulting files (including the intermediate steps) and perhaps a little extra space for temporary files that the ffmpeg may need (I'm not so sure of this). > 2. The document suggest that storage dir location should be on every > server, > org.opencastproject.storage.dir=/opt/matterhorn/felix/work/opencast > > As I understand, subfolders /downloads and /streams are created in > the final stage of processing, therefore these will be created on the > Engage server storage disk only? > If this is right, the largest disk for media storage should be then > allocated on the Engage server? > Or perhaps the org.opencastproject.storage.dir should be on the > shared volume? > I understand this should be in a shared volume, because all the relevant directories are subdirectories of this one by default. If so, such folders can be accessed from all the machines in the installation, even though they are only relevant for the engage player. Those folders are in the shared volume in Vigo, but this has to do with the fact that we never create VMs with large amounts of disk. Instead, we have a/some dedicated storage server(s) and the machines that need extra space mount a volume from that/those machine(s). Then, instead of assigning separate volumes for each Matterhorn server, we assign a very big volume to contain all the MH-relevant folders. Other scenarios, though, may call for different approaches. > 3. Where the repository file used during the media processing should be > allocated? > so the org.opencastproject.file.repo.path = > ${org.opencastproject.storage.dir}/files > Should this be on every server or on the shared volume? > In my understanding, this is not only used in the media processing, but it's like the "library" where all the content that has been processed is stored. Please others can correct me if I'm wrong. I think this should be in the shared volume, because its contents are relevant for all the different machines of the installation. If this is not shared, the files are retrieved via HTTP, which is slower. > 4. To which server the service registry should be allocated (this is > commented out on the single server installation)? > > org.opencastproject.serviceregistry.url=${org.opencastproject.server.url}/serviceregistry > The service registry doesn't have to do with the storage, but with the database. One of the servers in the installation has to run a database, and the others need to access that DB remotely, because different services require that. I don't know the specific cases, but in the case of the service registration, you can still have a server in your installation without granting its access to the database. Instead, it can use a REST service for that, but it needs to know the URL of one of the servers in the installation that has direct access to the database. In practice, if MH was compiled with the profile "service-registry", then you don't need to set this parameter, as the DB will be accessed with the credentials specified in the keys ".db.user", ".db.password" and so on. If, in turn, MH was compiled with the profile "service-registry-stub", then you need to set up this URL to one of the other servers that was compiled with the "service-registry" profile, and thus have direct access to the database. I know this explanation is a bit obscure, but I hope you understood me. > Many thanks in advance, > Leslaw > > > > > > > > > > > > > Dr Leslaw Zieleznik > OBIS (Oxford Brookes Information Solutions) > Oxford Brookes University > [email protected] > Tel: +44 (0)1865 483973 > > > > > > > _______________________________________________ > Matterhorn-users mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > >
_______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
