[
https://issues.apache.org/jira/browse/YARN-8849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640339#comment-16640339
]
Arun Suresh commented on YARN-8849:
-----------------------------------
Thanks for the comments [~leftnoteasy]
bq. If no container actually launched, how can we test changes like cgroups OOM
killer, utilization metrics collection from OS, etc.
So, the intention was to test components like the *ContainerManager*,
*ContainersMonitor* and *ContainerScheduler*. Especially in situations where we
have queuing and container churn, we felt a full fledged NM would be more
useful. I agree we wont be able to test a lot of the cgroups based code - but
we can still have the ContainerMonitor thread report pmem/vmem over the limit
based on some pre-specified utilization test plan and have the
ContainerScheduler make decisions. What we plan to do is plug in a custom
{{ResourceCalculatorProcessTree}} that can return a pre-specified resource
utilization over-time (a utilization 'plan') for a container without actually
running it.
bq. If one of the purpose is to handle the simulated NM / AM running with RM
inside the same process, we can run simulated AM/NM in a separate process /
machine to better isolate resource usage.
True - but then we would have to make a decision on how to split the NMs across
processes. Running the whole cluster as a YARN app might make it easier to make
those deployment specific decisions.
bq. Can we do large scale simulation by using relatively less number of
machines? (Like using 10 nodes to simulate 10k nodes).
Our intention was to use our existing large YARN clusters to scale the
simulated DynoYARN cluster. But if we could very well restrict deplyment to a
bunch of machines.. especially if we use Rich Placement Constraints with
affinity to group NMs.(obviously we will have to deal with starting NMs on uniq
ports.. but that is an implementation detail we plan to deal with)
One other possible usecase we failed to mention in the Description - which
Dynamometer originally tackled for HDFS - was to allow testing of a
different/later version of YARN on an older cluster before actually deploying
it. Our plan is to probably package this as a DistributedShell deployable app
which can probably be deployed on older clusters of YARN.
> DynoYARN: A simulation and testing infrastructure for YARN clusters
> -------------------------------------------------------------------
>
> Key: YARN-8849
> URL: https://issues.apache.org/jira/browse/YARN-8849
> Project: Hadoop YARN
> Issue Type: New Feature
> Reporter: Arun Suresh
> Assignee: Keqiu Hu
> Priority: Major
>
> Traditionally, YARN workload simulation is performed using SLS (Scheduler
> Load Simulator) which is packaged with YARN. It Essentially, starts a full
> fledged *ResourceManager*, but runs simulators for the *NodeManager* and the
> *ApplicationMaster* Containers. These simulators are lightweight and run in a
> threadpool. The NM simulators do not open any external ports and send
> (in-process) heartbeats to the ResourceManager.
> There are a couple of drawbacks with using the SLS:
> * It might be difficult to simulate really large clusters without having
> access to a very beefy box - since the NMs are launched as tasks in a
> threadpool, and each NM has to send periodic heartbeats to the RM.
> * Certain features (like YARN-1011) requires changes to the NodeManager -
> aspects such as queuing and selectively killing containers have to be
> incorporated into the existing NM Simulator which might make the simulator a
> bit heavy weight - there is a need for locking and synchronization.
> * Since the NM and AM are simulations, only the Scheduler is faithfully
> tested - it does not really perform an end-2-end test of a cluster.
> Therefore, drawing inspiration from
> [Dynamometer|https://github.com/linkedin/dynamometer], we propose a framework
> for YARN deployable YARN cluster - *DynoYARN* - for testing, with the
> following features:
> * The NM already has hooks to plug-in custom *ContainerExecutor* and
> *NodeResourceMonitor*. If we can plug-in a custom *ContainersMonitorImpl*'s
> Monitoring thread (and other modules like the LocalizationService), We can
> probably inject an Executor that does not actually launch containers and a
> Node and Container resource monitor that reports synthetic pre-specified
> Utilization metrics back to the RM.
> * Since we are launching fake containers, we cannot run normal AM
> containers. We can therefore, use *Unmanaged AM*'s to launch synthetic jobs.
> Essentially, a test workflow would look like this:
> * Launch a DynoYARN cluster.
> * Use the Unmanaged AM feature to directly negotiate with the DynaYARN
> Resource Manager for container tokens.
> * Use the container tokens from the RM to directly ask the DynoYARN Node
> Managers to start fake containers.
> * The DynoYARN NodeManagers will start the fake containers and report to the
> DynoYARN Resource Manager synthetically generated resource utilization for
> the containers (which will be injected via the *ContainerLaunchContext* and
> parsed by the plugged-in Container Executor).
> * The Scheduler will use the utilization report to schedule containers - we
> will be able to test allocation of *Opportunistic* containers based on
> resource utilization.
> * Since the DynoYARN Node Managers run the actual code paths, all preemption
> and queuing logic will be faithfully executed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
