What should I know about the shared disks in Oktawave?
Posted by Pomoc Oktawave on 16.02.2015 20:52
To use a shared disk in Oktawave, install the GFS2 or OCFS2 file system. This solution is suggested and validated by the administrators of our platform. As to the other (and sometimes better) shared file systems, the user has the possibility to use any one of them according to current needs.|
GFS2 and OCFS2 systems bring high complexity and potentially require high financial outlay in the implementation, as well as subsequent maintenance. Their advantage is, however, a very good data access time - thats why they are better than other solutions, such as CIFS or NFS. Furthermore, as an alternative to consider, we propose a solution based on GlusterFS - it is much easier to maintain and does not require a shared disk.
If the data access time is not important and we want a single point of data sharing between servers, the ideal solution is to use our OCS (which, incidentally, was created for such needs). However, to deploy OCS in existing applications, you must do a little extra work, i.e. rebuild the application to take from and write to data directly in the OCS, or use a mechanism that will allow to use OCS as a local drive eg. using Fuse (https://github.com/redbo/cloudfuse/).
Fuse has its limitations (eg. renaming folders does not work), but in most cases may be sufficient. In another case, user must rebuild the application.
In conclusion, the use of OCS will allow easy sharing of files and provide very high availability. Storing data in it also immunizes OCI for possible problems with local disks. Moreover, by using the OCS user can serve static content to the client browser without the application, which also is important for the service loading time.
Also keep in mind that the use of a shared disk in Oktawave may involve a machine restarts, which is related to the limitation on the side of the supplied VMware hypervisor used on our platform.
This limitation applies only to instances that use the shared drives and works in a way in which VMware Motion mechanism prevents smooth migration of instance with attached shared disk on the fly to another hardware-storage node. In other words, to update eg. only the hypervisor, VMware Motion allows us to smoothly update the instance without a shared disk (without rebooting), but prevents such an operation in relation to the shared disks in the interests of full data integrity.
There is currently no market solution allowing the shared disk operations in a virtualized environment, which would allow different behavior during environment migration.
Of course, we undertake to inform customers in advance of each restart and the action is carried out only when it is absolutely necessary (eg., if we need to update the virtualization platform).