Hi Douglas, > How does Univa Grid Engine work with GPUs?
In general or from within a container? In general we've been improving support for GPUs continuously since 2011 (newest features, Nvidia libraries, etc). Similar Phi and KNL. One thing that is special about Univa Grid Engine here is that the scheduler has full knowledge about the usage of GPUs and thus can avoid to dispatch workloads which would come in conflict regarding the GPU as a resource. Access to GPUs from within a containerized application also works and we are working on improvements there as well. Cheers, Fritz Sent from my iPhone > Am 04.08.2016 um 14:24 schrieb Douglas Duckworth <dod2...@med.cornell.edu>: > > I think the goal would be containerized compute nodes which could be deployed > as newer kernels, modules, compilers, and software become available. It > would be nice to offer bleeding edge without getting cut. > > How does Univa Grid Engine work with GPUs? > > http://doc.qnib.org/2014-11-05_Whitepaper_Docker-MPI-workload.pdf > http://insidehpc.com/2016/05/new-version-of-univa-grid-engine-now-supports-docker-containers/ > > Thanks, > > Douglas Duckworth, MSc, LFCS > HPC System Administrator > Physiology and Biophysics > Weill Cornell Medicine > E: d...@med.cornell.edu > O: 212-746-5454 > F: 212-746-8690 > >> On Thu, Aug 4, 2016 at 2:50 AM, Friedrich Ferstl <ffer...@univa.com> wrote: >> What do you want to accomplish, Simon? Run Grid Engine as a job processing >> service on top of Kubernetes which also runs other service workloads in >> parallel? Would you do so to be able to scale the size of the Grid Engine >> cluster? Or to make it fault tolerant or both? And would you want to run >> containerized workloads then also underneath Grid Engine? >> >> There is a solid amount of work we’ve done at Univa in this context. You may >> or may not be aware that we provide means to install Kubernetes clusters >> more easily with Navops Launch and we add sophisticated workload management >> policies to Kubernetes with Navops Command (see http://navops.io for more >> information). We also provide Docker integration to Grid Engine via Univa >> Grid Engine Container Edition. In those contexts we’ve done work to run Grid >> Engine on top of Kubernetes and it is not trivial. To do this more cleanly >> some changes were necessary like having a REST API for Grid Engine which we >> offer. >> >> If you are, on the other hand, are asking whether one can run high >> performance or high throughput workloads you typically would process via >> Grid Engine on top of Kubernetes instead then the answer leans towards a >> 'no'. Your mileage can always vary but Kubernetes really is geared at >> running persistent, microservice-based applications which can autoscale by >> adding or removing replicas of microservice instances. It does have a job >> concept but it is nothing similar to what you have in tools like Grid >> Engine. And that doesn’t even talk about the policies needed to manage >> diverse job-style workloads (sequential, parallel, arrays spread across >> coming from groups of users or projects, etc) or the scheduling performance >> required for throughput computing. >> >> So if you could specify your use case in more detail I might be able to >> provide a more targeted answer. >> >> Cheers, >> >> Fritz >> >>> Am 04.08.2016 um 07:01 schrieb Simon Matthews <simon.d.matth...@gmail.com>: >>> >>> Has anyone constructed a cluster using Kubernetes, Docker and >>> Gridengine (SGE or newer variants)? Does this even make sense? Is >>> there a better set of tools to achieve something similar? >>> >>> Simon >>> _______________________________________________ >>> users mailing list >>> users@gridengine.org >>> https://gridengine.org/mailman/listinfo/users >> >> Fritz Ferstl | CTO and Business Development, EMEA >> Univa Corporation | The Data Center Optimization Company >> E-Mail: ffer...@univa.com | Phone: +49.941.5695.9351 | Mobile: >> +49.170.819.7390 >
_______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
