Under construction to ARROW Cluster: Difference between revisions

From TRACC Wiki
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
== Introduction To ARROW ==
== Introduction To ARROW ==
TRACC has combined the original hardware from the Phoenix and Zephyr clusters into the ARROW cluster. This consolidation allows efficient administration of TRACC cluster services. To avoid the problems of load balancing, the different types of hardware nodes on the ARROW cluster are partitioned and available in queues. When new hardware is installed to expand cluster resources, it will be made available via a new queue.  
TRACC has combined the original hardware from the Phoenix and Zephyr clusters into the ARROW cluster. This consolidation allows efficient administration of TRACC cluster services with limited staff. To avoid the problems of load balancing, the different types of hardware nodes on the ARROW cluster are partitioned and available in queues. When new hardware is installed to expand cluster resources, it will be made available via a new queue. The documentation at [[Using the Cluster]] describes procedures for using ARROW.
<p>ARROW is arranged such that there is a single set of 4 login nodes, a singe file system, and single user home directory that serves all of the nodes in all of the queues.
<p>ARROW is arranged such that there is a single set of 4 login nodes, a singe file system, and single user home directory that serves all of the nodes in all of the queues.
Further all nodes on ARROW are logically divided into one scheduling system or another. The first scheduling system is called Torque and Maui (called Torque in the rest of this presentation) and the second scheduling system is called is called PBS.<p>


Current job submission system- By default, we are currently using Torque as our queuing system. Jobs can be submitted from any of the login nodes. Once a job starts, the nodes assigned to that user are generally accessible by additional ssh sessions from any other node in the system. For example, if you submit a job from login1, you can go to login2 and create an ssh session to the node that was handed out by the scheduler. Think of it as a global resource allocation that gives you access to a few nodes that you can do anything on as you desire until the job time expires. This is true for interactive and batch sessions, it’s all the same. Any node assigned to a user is fully allocated to that user, and a job can only ask for full nodes. No other users can share a node that has been handed out to a user. The queues are used to get certain CPU types for the job.
== ARROW Queues==
There are currently several queues that are available, some with restrictions about who can use them as described below. Also be aware that all nodes in some queues have the same characteristics (RAM, etc) while some queues have nodes with different characteristics. Thus jobs using those queues must specify the node names that are to be used.
 
* batch queue (default queue)
** 95 nodes numbered n005 through n099
** 2 x AMD Opteron 6276
** 16 floating point cores per node
** 32GB of RAM per node
** available for general use
 
* batch128 queue
** 2 nodes numbered n001 and n002
** Same design as batch queue
** 128GB of RAM per node
** available for general use
 
* batch64 queue
** 2 nodes numbered n003 and n004
** Same design as batch queue
** 64GB of RAM per node
** available for general use
 
* nhtsa queue
** 12 nodes numbered p001 through p012
** 2 x Intel Xeon E5-2690 v4
** 28 floating point cores per node
** 64GB of RAM per node
** only available to the NHTSA project
 
* arrow queue
** 15 nodes numbered a001 through a015
** 1 x Intel EPYC 7702P
** 64 floating point cores per node
** 256GB of RAM per node, 512GB on nodes a001 through a003
** available for general use
 
* extra queue
** 12 nodes numbered a0016 through a027
** 1 x Intel EPYC 7713P
** 64 floating point cores per node
** 256GB of RAM per node, 512GB on nodes a018 through a022
** available for general use
** note: this queue will likely be merged into the arrow queue in the future
 
* virtual queue
** 5 nodes numbered v001 through v005
** Mostly for internal testing and validation, can be used as 2 core machines with 32GB memory
** Minimal virtual hardware, not capable of running engineering applications

Revision as of 22:34, January 28, 2025

Introduction To ARROW

TRACC has combined the original hardware from the Phoenix and Zephyr clusters into the ARROW cluster. This consolidation allows efficient administration of TRACC cluster services with limited staff. To avoid the problems of load balancing, the different types of hardware nodes on the ARROW cluster are partitioned and available in queues. When new hardware is installed to expand cluster resources, it will be made available via a new queue. The documentation at Using the Cluster describes procedures for using ARROW.

ARROW is arranged such that there is a single set of 4 login nodes, a singe file system, and single user home directory that serves all of the nodes in all of the queues.

ARROW Queues

There are currently several queues that are available, some with restrictions about who can use them as described below. Also be aware that all nodes in some queues have the same characteristics (RAM, etc) while some queues have nodes with different characteristics. Thus jobs using those queues must specify the node names that are to be used.

  • batch queue (default queue)
    • 95 nodes numbered n005 through n099
    • 2 x AMD Opteron 6276
    • 16 floating point cores per node
    • 32GB of RAM per node
    • available for general use
  • batch128 queue
    • 2 nodes numbered n001 and n002
    • Same design as batch queue
    • 128GB of RAM per node
    • available for general use
  • batch64 queue
    • 2 nodes numbered n003 and n004
    • Same design as batch queue
    • 64GB of RAM per node
    • available for general use
  • nhtsa queue
    • 12 nodes numbered p001 through p012
    • 2 x Intel Xeon E5-2690 v4
    • 28 floating point cores per node
    • 64GB of RAM per node
    • only available to the NHTSA project
  • arrow queue
    • 15 nodes numbered a001 through a015
    • 1 x Intel EPYC 7702P
    • 64 floating point cores per node
    • 256GB of RAM per node, 512GB on nodes a001 through a003
    • available for general use
  • extra queue
    • 12 nodes numbered a0016 through a027
    • 1 x Intel EPYC 7713P
    • 64 floating point cores per node
    • 256GB of RAM per node, 512GB on nodes a018 through a022
    • available for general use
    • note: this queue will likely be merged into the arrow queue in the future
  • virtual queue
    • 5 nodes numbered v001 through v005
    • Mostly for internal testing and validation, can be used as 2 core machines with 32GB memory
    • Minimal virtual hardware, not capable of running engineering applications
Retrieved from "https://wiki.anl.gov/wiki_tracc/index.php?title=Under_construction_to_ARROW_Cluster&oldid=2010"