tf.train.ClusterSpec({
"worker": [
"worker0.example.com:2222", //主机名也可以使用IP
"worker1.example.com:2222",
"worker2.example.com:2222"
],
"ps": [
"ps0.example.com:2222",
"ps1.example.com:2222"
]})训练时TensorFlow各个Task资源无法隔离，很有可能会导致任务间因资源抢占互相影响。
缺乏调度能力，需要用户手动配置和管理任务的计算资源。
集群规模大时，训练任务的管理很麻烦，要跟踪和管理每个任务的状态，需要在上层做大量开发。
用户要查看各个Task的训练日志需要找出对应的服务器，并ssh过去，非常不方便。
TensorFlow原生支持的后端文件系统只支持：标准Posix文件系统（比如NFS）、HDFS、GCS、memory-mapped-file。大多数企业中数据都是存在大数据平台，因此以HDFS为主。然而，HDFS的Read性能并不是很好。
当你试着去创建一个大规模TensorFlow集群时，发现并不轻松。
提供ResourceQuota、LimitRanger等多种资源管理机制，能做到任务之间很好的资源隔离。
支持任务的计算资源的配置和调度。
训练任务以容器方式运行，Kubernetes提供全套的容器PLEG接口，因此任务状态的管理很方便。
轻松对接EFK/ELK等日志方案，用户能方便的查看任务日志。
支持Read性能更优秀的分布式存储（GlusterFS），但目前我们也还没对接GlusterFS，有计划但没人力。
通过声明式文件实现轻松快捷的创建一个大规模TensorFlow集群。
kind: Job
apiVersion: batch/v1
metadata:
name: {{ name }}-{{ task_type }}-{{ i }}
namespace: {{ name }}
spec:
template:
metadata:
labels:
name: {{ name }}
job: {{ task_type }}
task: "{{ i }}"
spec:
imagePullSecrets:
- name: harborsecret
containers:
- name: {{ name }}-{{ task_type }}-{{ i }}
image: {{ image }}
resources:
requests:
memory: "4Gi"
cpu: "500m"
ports:
- containerPort: 2222
command: ["/bin/sh", "-c", "export CLASSPATH=.:/usr/lib/jvm/java-1.8.0/lib/tools.jar:$(/usr/lib/hadoop-2.6.1/bin/hadoop classpath --glob); wget -r -nH -np --cut-dir=1 -R 'index.html*,*gif' {{ script }}; cd ./{{ name }}; sh ./run.sh {{ ps_hosts() }} {{ worker_hosts() }} {{ task_type }} {{ i }} {{ ps_replicas }} {{ worker_replicas }}"]
restartPolicy: OnFailurekind: Deployment
apiVersion: extensions/v1beta1
metadata:
name: {{ name }}-{{ task_type }}-{{ i }}
namespace: {{ name }}
spec:
replicas: 1
template:
metadata:
labels:
name: {{ name }}
job: {{ task_type }}
task: "{{ i }}"
spec:
imagePullSecrets:
- name: harborsecret
containers:
- name: {{ name }}-{{ task_type }}-{{ i }}
image: {{ image }}
resources:
requests:
memory: "4Gi"
cpu: "500m"
ports:
- containerPort: 2222
command: ["/bin/sh", "-c","export CLASSPATH=.:/usr/lib/jvm/java-1.8.0/lib/tools.jar:$(/usr/lib/hadoop-2.6.1/bin/hadoop classpath --glob); wget -r -nH -np --cut-dir=1 -R 'index.html*,*gif' {{ script }}; cd ./{{ name }}; sh ./run.sh {{ ps_hosts() }} {{ worker_hosts() }} {{ task_type }} {{ i }} {{ ps_replicas }} {{ worker_replicas }}"]
restartPolicy: Always
kind: Service
apiVersion: v1
metadata:
name: {{ name }}-{{ task_type }}-{{ i }}
namespace: {{ name }}
spec:
clusterIP: None
selector:
name: {{ name }}
job: {{ task_type }}
task: "{{ i }}"
ports:
- port: {{ port }}
targetPort: 2222
支持基于训练优先级的任务抢占式调度：用户在TaaS上创建TensorFlow训练项目时，可以指定项目的优先级为生产（Production）、迭代（Iteration）、调研（PTR），默认为迭代。优先级从高到低依次为Production --> Iteration --> PTR。但集群资源不足时，按照任务优先级进行抢占式调度。
提供像Yarn形式的资源分配视图，让用户对自己的所有训练项目的资源占用情况变得清晰。
训练和预测的混合部署，提供数据中心资源利用率。
……
Contiv Netplugin的问题，在DevOps环境中还是稳定的，在大规模高并发的AI场景，问题就层出不穷了，产生大量垃圾IP和Openflow流表，直接把Node都成NotReady了，具体的不多说，因为据我了解，现在用这个插件的公司已经很少了，想了解的私下找我。
在我们的方案中，一个TensorFlow训练集群就对应一个Kubernetes Namespace，项目初期我们并没有对及时清理垃圾Namespace，到后来集群里上万Namespace的时候，整个Kubernetes集群的相关API性能非常差了，导致TaaS的用户体验非常差。
TensorFlow gRPC性能差，上千个Worker的训练集群，概率性的出现这样的报错：grpc_chttp2_stream request on server; last grpc_chttp2_stream id=231, new grpc_chttp2_stream id=227，只能尝试通过升级TensorFlow来升级gRPC了。目前我们通过增加单个Worker的计算负载来减少Worker数量的方法，减少gRPC压力。除此之外，规模大一点TensorFlow还有各种问题，甚至还有自己的OOM机制，防不胜防。不过，高速成长的东西，我们要给它足够的容忍。
还有TensorFlow OOM的问题等等。
1974
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
