Re: [slurm-users] Several slurmdbds against one mysql server?
Ole is spot on with his federated suggestion. That is exactly what fits the bill for you, given your requirements. You can have everything you want, but you don't get to have it how you want (separate databases). When/If you looked deeper into it, you will find that it addresses the requirements. This looks more like an instance where "I have a solution, please agree with me and help me make it work." Something, I am confident many of the folks here run into. Look at your requirements rather than your solution. On a technical note: slurm keeps the detailed accounting data for each cluster in separate TABLES within a single database. If you want to have separate databases, it will be on you to do all the aggregation work from separate queries. I am doing just that because I have separate databases for each of my clusters. This is because each cluster is in a different part of the world and trying to federate them in a performant manner was prohibitively expensive. Brian Andrus On 4/29/2023 10:53 PM, Angel de Vicente wrote: Hi Ole, Ole Holm Nielsen writes: Maybe you want to use Slurm federated clusters with a single database thanks for the links, but federated clusters is not what I need. I want to have separate clusters, with different users, job IDs, etc. and the only think that I want to aggregate is their databases, to simplify my life when gathering stats. My question was, then, to try and understand the pros and cons of having several slurmdbds or just one. Cheers,
Re: [slurm-users] Several slurmdbds against one mysql server?
Hello, Brian Andrus writes: > Ole is spot on with his federated suggestion. That is exactly what fits the > bill > for you, given your requirements. You can have everything you want, but you > don't get to have it how you want (separate databases). > When/If you looked deeper into it, you will find that it addresses the > requirements. I might be missing something but I don't see how a Slurm federated cluster does what I need. From https://slurm.schedmd.com/federation.html: , | Jobs submitted to a federation receive a unique job ID that is unique | among all clusters in the federation. A job is submitted to the local | cluster (the cluster defined in the slurm.conf) and is then replicated | across the clusters in the federation. Each cluster then independently | attempts to the schedule the job based off of its own scheduling | policies. The clusters coordinate with the "origin" cluster (cluster the | job was submitted to) to schedule the job. ` + I don't want unique job IDs among all clusters + When I submit a job to a local cluster, I don't want each cluster to try and schedule the jobs, I just want the local cluster to schedule it. + I want to keep the clusters wholly independent, EXCEPT for keeping all the data regarding job statistics in a single database. Cheers, -- Ángel de Vicente Research Software Engineer (Supercomputing and BigData) Tel.: +34 922-605-747 Web.: http://research.iac.es/proyecto/polmag/ GPG: 0x8BDC390B69033F52 smime.p7s Description: S/MIME cryptographic signature
Re: [slurm-users] Several slurmdbds against one mysql server?
Not wanting something is not the same as not needing it or it matters. Personally, I don't care what color it is, if someone gave me a new Ferrari, I would not worry about the color. Do you need to have the same job ids among clusters? Seems that should not matter at all. The clusters ARE wholly independent. When you submit a job, UNLESS you tell it to run on a different cluster, it will go to the default one for that node (ie the one configured in the local slurm.conf). It gives you the ability to submit to another cluster, but by no means do you have to do that. You should consider your needs. You are claiming you need both an irresistible force and an immovable object. You want your reports to be able to be consolidated and/or separate. Federated does that. Having other benefits that you won't use should be superfluous and not have any bearing. You can do it however you like. You asked if there was a good or existing way to do it easily, that was provided. Up to you if you want to write your own scripts that do the work and manage that, or just have to learn the ins and outs of running sreport. Good luck. On 4/30/2023 2:38 PM, Angel de Vicente wrote: Hello, Brian Andrus writes: Ole is spot on with his federated suggestion. That is exactly what fits the bill for you, given your requirements. You can have everything you want, but you don't get to have it how you want (separate databases). When/If you looked deeper into it, you will find that it addresses the requirements. I might be missing something but I don't see how a Slurm federated cluster does what I need. From https://slurm.schedmd.com/federation.html: , | Jobs submitted to a federation receive a unique job ID that is unique | among all clusters in the federation. A job is submitted to the local | cluster (the cluster defined in the slurm.conf) and is then replicated | across the clusters in the federation. Each cluster then independently | attempts to the schedule the job based off of its own scheduling | policies. The clusters coordinate with the "origin" cluster (cluster the | job was submitted to) to schedule the job. ` + I don't want unique job IDs among all clusters + When I submit a job to a local cluster, I don't want each cluster to try and schedule the jobs, I just want the local cluster to schedule it. + I want to keep the clusters wholly independent, EXCEPT for keeping all the data regarding job statistics in a single database. Cheers,
